Version: 1.6 (using Devel) Compiler: Visual Studio 2008 OS: MS Windows Installed from: Compiled sources TagLib seems to be having problems with updating the Vorbis comments of certain FLAC files. When using the supplied tagwriter example to change a tag of such a FLAC file, tagreader still shows the old value for this tag afterwards. Inspecting the contents of the file reveals that TagLib has written a new comment block before the old one, but still reads from the old comment block. I would be happy to send this file to one of the developers, just let me know to what address.
Hi, I'm not sure if you got my mail on the mailing list, but it would be useful if you could send me the file to lalinsky@gmail.com. Thank you.
I saw your mail on the mailinglist, and I did send you the file, exactly 1 week ago. You haven't received it? :/ (it was a yousendit.com link) I can resend the file, but not before tomorrow evening (I'm at another computer right now, and don't have the file here).
Ouch, Gmail marked the mail as spam for some reason. :( Sorry about that. Unfortunately the link has expired by now, so if you could send it again, it would be great.
No problem. Resending it will be one of the first things I'll do when I get back to the other PC tomorrow.
I have just uploaded the file again and sent you the link. Did you get it?
Yes, I got the file. Thank you. Here is the problem: The file has 5 (yes, five! :)) duplicate Vorbis Comment blocks. TagLib reads tags from the last one, but updates the first one.
That doesn't really sound like the correct behaviour, shouldn't it update the same comment block it reads from? Those 5 blocks could have been caused by the user already applying TagLib and some other tagging tools on the file. Should I ask him to send a 'clean' file as well?
Yes, it should read and write to the first block (after some tests, applications are not consistent which block to use, but the original flac code is using the first one). I don't think TagLib produced the duplicate blocks, but if you can ask him how was the file encoded and tagged, it would help.
He told me that it was created by ripping a CD track to FLAC with Exact Audio Copy, so that's probably the standard FLAC encoder (FLAC.exe) that's included with this program.
Well, the vorbis comment blocks have one fairly non-standard tag "LOCATION=Provider=AMG". I don't know if your application writes this tag, but if it doesn't, it would be useful to know whether it's EAC or some other tagging program. That means, to make sure TagLib doesn't cause this problem, I'd need to know which programs wrote something to the file.
The LOCATION tag isn't standard? It is listed as one of the standard tags at http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-850005.2.2 . Or is it because of the equal-sign in its value, isn't this allowed? Anyway, my application (WMP Tag Plus, it's actually more a plug-in) doesn't write the LOCATION tag. I'll ask him if he used any other tagging programs.
I meant that's specific enough to identify the application that wrote the tag.
Hello, here the owner of the file discussed here. Tim asked me to post some info here. I have created files with EAC. After that I have used (some months ago) the WMP Tag Support Extender (check: http://wmptagext.sourceforge.net/) to write tags (using WMP). But that never worked for me. Allthough WMP showed the updated tags, there were actually not written to the FLAC files. After that I have starting using the pluging Tim has made. Should I try to remove all tags (if there is such a program, that can do it) and try to write it again? Or is that useless?
It would be useful if you could try to reproduce the problem from scratch and save a copy of the file at each point (that is, rip with EAC, save a copy, tag with wmptagext, save a copy, ideally do the same with wmptagext again, then try to save tags with WMP Tag Plus and save a copy). Given that with the file as you sent it, TagLib doesn't add more vorbis comment blocks, I don't think it's a bug in TagLib, but the only way to be sure is to compare the files before and after saving with wmptagext. The main problem in TagLib is that it reads tags from a different block than it writes to. This is easy to fix and will be done in any case. I'd just like to make sure that TagLib doesn't caused the original problem with multiple VC blocks.
"Provider=AMG" definitely looks like a WMP tag value. wmptagext fills the LOCATION tag with WMP's ProviderURL attribute, so this is most likely added by wmptagext. It wouldn't surprise me if this plug-in is responsible for the multiple comment blocks as well. The weird thing is that wmptagext never actually wrote back the changes to the FLAC files, according to Loek. I have done some testing with wmptagext myself, but it didn't write any changes either. Lukáš, maybe you can take a look at wmptagext's source code, and see if there's anything that could be adding multiple comment blocks?
Hey Lukas, I'm pretty sure that taglib didn't cause the multiple tag blocks. In fact: I think it is trying to correct the problem. Here is why: I have a flac file from february 2009 which I have altered with wmptagext pluging, but I haven't altered with the plugin Tim has made. That flac file has really weird comment blocks. When I hover over the file with audioshell it shows me this (in this example artist = blof, title = Aan de kust, tracknumber is 01) artist: blof blof blof blof title: aan de kust aan de kust aan de kust aan de kust track #: 01 01 01 01 The flac files I was able to edit with Tim's plugin don't show these multiple inputs anymore with audioshell! (but problem is not solved..) You write that "The main problem in TagLib is that it reads tags from a different block than it writes to. This is easy to fix and will be done in any case." I hope it can be done easy indeed, because I would love to get my music database organised with help of Tim's plugin.
SVN commit 1043985 by lalinsky: Always read tags from the first Vorbis Comment block in FLAC files Prevously TagLib saved tags to the first block, but read them from the last one. Having multiple VC blocks is a non-standard situation, but this is the best we can do (libFLAC also uses the first block in the case of multiple VC blocks). BUG:211089 M +7 -3 taglib/flac/flacfile.cpp M +1 -0 tests/CMakeLists.txt AM tests/data/multiple-vc.flac AM tests/test_flac.cpp [License: UNKNOWN] WebSVN link: http://websvn.kde.org/?view=rev&revision=1043985
Thanks, the problem is now fixed in SVN.
Thank you for fixing this :) Is it wise to include this latest revision into my plug-in? Or should I wait for the official release of TagLib 1.6.2?
It's fine to use the SVN code in your plugin. It's not a high-priority problem, as it affects only minimum of files, so I'm not planning 1.6.2 for now.
thnx!