First results of my evaluation of taglib against id3tag
xavier.duret at caramail.com
Wed Jan 10 12:50:34 CET 2007
> Does this file happen to be VBR? Chances are that this file is a variable bit-rate file without a Xing header. These files's lenghts cannot be determined accurately without scanning and parsing ever frame of the file.
I disabled full scan in Firefly and started getting wrong duration estimates so you are probably right.
> Making this assumption, as far as taglib and VBR-sans-Xing, I was thinking of working on having taglib do the accurate calculation as at the Amarok list and IRC channel we've gotten some complaints. But after talking with some other people I'm no longer convinced that this is the best thing to do. People whose collections are mostly VBR-sans-Xing will incur huge overhead any time they load a file, scan collections, etc.
Let me play advocate of the devil for a bit and keep in mind that my personal collection is ogg vorbis with some m4a files.
I think the line of thought exposed in the bug report is wrong. It states that the files are broken and should be fixed. I agree with that. But then they go and say that taglib should silently report garbage when this happens (garbage in, garbage out). This is wrong. A fundamental library like taglib should be trustworthy. You cannot expect Joe Sixpack to see his media player output trash and deduct that his files are broken and that he should fix them. He is probably going to consider that the program is buggy.
So how do you deal with that? Simple: you inform the user that the file is broken. A possibility goes like this:
- A new function in the C bindings (and C++) is added: "int taglib_is_file_broken()". Dumping a warning on stderr is not good enough because the end user usually does not see stderr (think Amarok).
- The media player (like Amarok) calls taglib as usual and add a call to the previously defined function. If the file is broken, the media player shows a passive pop up informing the user about the problem and providing it with a solution.
Then there are 2 possibilities:
- You play hardball. The user is warned and will not get any information related to its file until it takes the necessary steps. At least, it know that is wrong and what it has to do.
- You play softball. The user is warned but taglib will be nice and scan the entire file to give the user what it wants. The warning pop up will explain to the user why everything is so slow and help him to do the right thing. The media player could him propose to fix the files itself (provided that no other program is using them at that moment).
So do you think I am reasonable or just plain crazy?
> Please see <a href=http://lists.kde.org/?l=kde-bugs-dist&m=116688576526501&w=2>http://lists.kde.org/?l=kde-bugs-dist&m=116688576526501&w=2</a>
Very clear to me but do not expect Joe Sixpack to find this out. Given that a port of Amarok to Windows is planned, prepare to have many more Joe Sixpack users complaining...
Gagnez tous les jours un iPod nano. Inscrivez-vous au courriel gratuit CaraMail. Et bénéficiez de 10 SMS gratuits ! Cliquez ici pour gagner : http://promotion.lycos.fr/
More information about the taglib-devel