Bug 3520 - ID3 tags not parsed when APE tags present
: ID3 tags not parsed when APE tags present
Status: CLOSED WORKSFORME
Product: Logitech Media Server
Classification: Unclassified
Component: Tagging
: 6.2.2
: All Other
: P2 major (vote)
: ---
Assigned To: Squeezebox QA Team email alias
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-10 02:34 UTC by Glenn Richards
Modified: 2011-03-16 04:40 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments
MP3.pm patch (748 bytes, patch)
2006-06-19 10:36 UTC, Jason Holtzapple
Details | Diff
mp3 file with id3v1 and mp3gain ape tags (5.00 MB, audio/mpeg)
2007-10-19 09:17 UTC, Jason Holtzapple
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Glenn Richards 2006-06-10 02:34:18 UTC
When scanning my music library, no tag information was retrieved from any of the files. A quick post on the forum suggested it was the presence of an APE tag that was preventing the server from retrieving the ID3 tag data, which indeed turned out to be the case.

Unfortunately removing APE tags from my MP3 files is not an option (these are added by MP3gain) as the level adjustments are used in various other pieces of software. I've come up with a temporary workaround by disabling the calls to the APE tag parsing code in the relevant Info.pl file, unfortunately this means that volume levelling information is no longer available to SlimServer.

This problem only seems to occur when an ID3v2 tag is not present - the presence of an APE tag appears to blank all the fields that also appear in the ID3v1 tag. The correct behaviour should be to only replace ID3v1 fields that actually appear in the APE tag. Again, switching 9,000 MP3 files to ID3v2 tags is not an option, partly because I still have some old legacy software that chokes on v2 tags.
Comment 1 KDF 2006-06-10 11:04:40 UTC
please try 6.3 nightly builds
Comment 2 Blackketter Dean 2006-06-11 22:20:45 UTC
Also, if it's still happening with 6.3, please attach a file that exhibits this problem.
Comment 3 Jason Holtzapple 2006-06-19 10:36:32 UTC
Created attachment 1276 [details]
MP3.pm patch
Comment 4 Jason Holtzapple 2006-06-19 10:37:53 UTC
The problem still exists in 6.3 I think it is a side effect of the change always preferring id3v2 over id3v1 (for iTunes) rather than merging the two while preferring id3v2 (old behavior).

I'm in the same boat as the original problem reporter (thousands of files affected).

I work around it with the patch attached but this has the side effect of increasing rescan time by a significant amount.
Comment 5 Dan Sully 2006-06-26 17:39:00 UTC
Should be fixed in change 8143
Comment 6 Jason Holtzapple 2007-10-18 21:43:03 UTC
I tried upgrading from 6.5.4 to svn 13906. After a rescan, I'm getting the same behavior that I was for this bug. I believe the logic for handling id3v1 + ape (mp3gain) has reverted and I'm missing thousands of tracks from the scan like I was before.
Comment 7 Andy Grundman 2007-10-19 07:19:53 UTC
Could you please attach a file that is not scanned properly?
Comment 8 Jason Holtzapple 2007-10-19 09:17:36 UTC
Created attachment 2285 [details]
mp3 file with id3v1 and mp3gain ape tags
Comment 9 Andy Grundman 2007-10-20 06:10:07 UTC
I can't reproduce your problem.  This file is scanned fine and appears in the library with proper metadata and replaygain info.  Tested with svn 13949.
Comment 10 Jason Holtzapple 2007-10-20 07:27:47 UTC
It's still ocurring on my server, but it's clear now that it is a different bug than this one. I filed https://bugs-archive.lyrion.org/show_bug.cgi?id=5872
Comment 11 Chris Owens 2008-03-07 09:04:45 UTC
This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.