Bugzilla – Bug 4665
APEv2 tags supercede id3 and id3v2 tags
Last modified: 2009-10-05 14:35:39 UTC
Hi, I've noticed an extremely annoying aspect of the way the scanner uses the perl MP3::Info library. If an MP3 has APEv2 (i.e., has an APETAGEX at the end) Artist (and probably others, but artist is all I've tested) tags at the end, they will supercede whatever id3 tags are present in the file. As far as I know this is undocumented and inintended. It is made especially annoying by the fact that I can't find any command line utilities to strip these tags out of MP3 files. I can use an id3 (or id3v2) editor to fix broken tags, but, because the slimserver defers to the non-standards APE tags, things remain busted. I hacked around this problem by hacking lib/MP3/Info.pm to always ignore these tags, but that's probably a non-optimal solution. Ben
question is, how did they get there? The idea behind using APE2 tags is that if they have been added, then the user is tending them to be used. There by mistake...well, I think everyone would love to know what logic can be used to be 100% sure of intent.
Well, in this case, they were added by a dumbass friend who can't spell. The problem is that it's easy to edit id3 tags but hard to change APE tags AND that APE tags supercede id3.
So, what kind of solution would you like to see? In most cases, users that have APE tags want them to supercede 'lesser' tags. :) I've heard the idea of a tag-type prioritization scheme kicked around. Would that be suitable? Or would it add more complexity than it's worth?
I think by default id3 tags, which are standard, should supercede non-standard APE tags, at least for mp3s. It would be cool if they could be prioritized by users, but until them, having the standard be the standard makes more sense, no? Also, it seems to me that users who are into their APE tags should have the wherewithall to modify them or id3 tags or make the later match the former. Ben
(In reply to comment #4) > I think by default id3 tags, which are standard, should supercede non-standard > APE tags, at least for mp3s. That makes a lot more sense to me as well. I can't see why APE tags should have precedence over id3 in an mp3 file. Nearly any file tagger will work with id3 tags on mp3s, but they may not be able to edit, read or remove the APE tags in these files.
The concensus here at Slim now is that maybe id3v2 tags should supercede others. Really, if you have multiple tags, you should try where possible to make sure that they are the same. Andy to ask Dan S. about what the original reasoning was.
Andy: ever hear anything from Dan?
Yeah Dan said there was a big discussion about this a while ago, resulting in the current behavior, so I am not really inclined to change it.
The workaround is to fix your tags :) We're marking this as 'wontfix' for now, but please add your comments so we can revisit this in the future.
I vote for re-opening this bug and giving the user an option which kind of tag they want scanner to read (ID3 v1, v2 or APE) for their mp3 (!!) files. I totally agree with Jim's comment #5: Most mp3 tag editors out there do not even support reading or modifying APE tags. It took me quite some time to figure out that scanner is prioritizing APE tags, and it's not easy to remove the APE tags....
The argument can be made that if you don't want APE tag data being read, you should not put APE tags in your mp3 files...
The problem is that there exists a default tag prioritization scheme that cannot be altered by the end-user. The solution is to allow the user control over the tag prioritization scheme. Any other argument is either an excuse not to perform the required work or an argument for the sake of argument. The fact is that multiple tag formats exist, and new tag formats will eventually be created in the future. Asking a user to re-tag potentially thousands of files is not a reasonable request. As it stands now, APEv2 comprises a very small percentage of the tags in existence. ID3 is the OVERWHELMINGLY popular format. Setting the priority against the 'greatest-good' makes little sense. This is not a bug, its a feature. And if someone can provide a usability reason why it is more beneficial to have the priority hard-coded rather than user-selectable I'd be interested to hear it.
Afters hours of searching why I have tracks with a typo in the track name under SC, even though the tack name shows up fine in every other mp3 player or tag editor I tried, I finally dumped the raw mP3 file and saw this ape tag stuff. Hours later, after trying to find a tool on max os x that would strip off these ape tags (I did not found any), and then finally finding this bug... ... I have only one thing to say : please provide a way to have SC ignore an APE tag if there is an equivalent APE tag. Do this as an option if you prefer to keep providing the current behavior, but please, do something to help with this issue... !
Is there a reason why you won't fix it?
Actually, in 7.4, Audio::Scan reads both APE and ID3 tags, but the ID3 tags take precedence, and will overwrite any APE tags that match. Is that good enough to fix this issue?
Perfect, thanks Andy!
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.