PDA

View Full Version : Corrupt 'Comments' tag on iTunes-ripped tracks



Tradewind25
2006-11-15, 04:45
I've recently started to rip albums using iTunes 7.0.2 and I am seeing some weird text appearing in the "Comments" tag when I view the tracks on SlimServer/Squeezebox.

Example:
========
1. Rip an album in iTunes. View the track info in iTunes and the "Comments" tags appear empty.
2. Check the iTunes Music Library.xml file. There are no comments against these tracks.
3. Do a complete rescan in SlimServer. View the track info and I see comments like:
"iTunPGAP 0 / iTunSMPB 00000000 00000210 000009E4 0000000000B7540C 00000000 0072DE0F 00000000 00000000 00000000 00000000 00000000 00000000"
4. Open the track in another music player (Roxio's Audiocentral) and it sees a comments tag of "0".

Conclusion (so far)
===================
The Comments tag data is corrupt in the mp3 file produced by iTunes.

Anyone else experienced this?

Tradewind25
2006-11-15, 07:14
I've now established (using the MP3Tag Editor freeware) that the files produced by iTunes conTAin the following comment tags. These seem to be specific to MP3, since files I have ripped in iTunes using AAC do not contain these.
COMMENT ITUNPGAP = 0
COMMENT ITUNSMPB = 00000000 00000210 ...

radish
2006-11-15, 08:23
Those are the tags iTunes adds for it's new gapless playback feature. Slimserver probably shouldn't be displaying them...

Tradewind25
2006-11-15, 08:28
Thanks for the prompt response.
I suspected from its name (TunPGAP)that this may be a "gapless" issue.
I have emailed SlimDevices' Tech Support for their comments.

gerph
2006-11-15, 17:53
I've recently started to rip albums using iTunes 7.0.2 and I am seeing some weird text appearing in the "Comments" tag when I view the tracks on SlimServer/Squeezebox.

Example:
========
1. Rip an album in iTunes. View the track info in iTunes and the "Comments" tags appear empty.
2. Check the iTunes Music Library.xml file. There are no comments against these tracks.
3. Do a complete rescan in SlimServer. View the track info and I see comments like:
"iTunPGAP 0 / iTunSMPB 00000000 00000210 000009E4 0000000000B7540C 00000000 0072DE0F 00000000 00000000 00000000 00000000 00000000 00000000"
4. Open the track in another music player (Roxio's Audiocentral) and it sees a comments tag of "0".

Conclusion (so far)
===================
The Comments tag data is corrupt in the mp3 file produced by iTunes.

Anyone else experienced this?

I don't think it's corrupt.

I've just downloaded and installed 7.0.2 of that horrid software just to investigate this problem. I'm shocked (ok, maybe that's a little extreme... 'very surprised') that iTunes is still using version ID3v2.2. I thought everyone stopped using that so many years ago. Anyhow, that's what they're using, so that's what I've got to look at <sob>.

The comment fields added are for the comment types iTunPGAP, iTunNORM, iTunSMPB and iTunes_CDDB_IDs. The interpretation of these appears to be correct to me. The COM frame (COMM in later specification versions) is intended as a replacement for the ID3v1 comment field (see ID3v2.2 section 4.11 for the exact statement). Placing non-comment information (ie stuff that's meant to be interpretted) should (IMO) be in the PRIV frame, but this only appeared in ID3v2.3 - yet another reason why people should be using at /least/ ID3v2.3. The PRIV frame is documented in the ID3v2.3 specification in section 4.28 - it is explisitly 'used to contain information from a software producer that its program uses and does not fit into the other frames'.

Regardless of this, the 4 comment fields do appear to be interpreted correctly by the MP3::Info plugin - which is as far as I've looked. You didn't say which version of the server you were using. I've got an MP3::Info lying around from the 6.2 server (I believe it's version 1.21 of the module anyhow) and that shows up the comment field as '0'. The current trunk version shows up the 4 fields correctly.

In case anyone else investigating the problem wants to check with an iTunes generated file, I've put a copy of the ID3v2.2 header and a couple of empty MP3 frames up at http://usenet.gerph.org/ID3/Hawaii78.mp3 and the decoded values from the MP3::Info processor are at http://usenet.gerph.org/ID3/Hawaii78.txt.

Amusingly (!) according to the MP3::Info sources, J River Media Center uses a COMM field in a similar way. These are internally promoted to TXXX fields, rather than PRIV. It's possible that the same promotion should be applied to the iTunes comment frames.

Tradewind25
2006-11-16, 01:12
Many thnaks for all your hard work on this Gerph.

I guess "corruption" was perhaps too strong a word, but when this stuff first popped up in SlimServer it looked like garbage to me. Now I understand that it is legitimate data as far as iTunes is concerned, albeit it could perhaps have been recorded in a better place.
FYI: I am using SlimServer version 6.5.1 - 10638 - Windows XP - EN - cp1252.

Since I'm unlikely to be able to persuade Apple to move from ID3v2.2 to v2.3 too quickly, I guess my best bet is to ask those nice guys at Slim if they could get their software to ignore these particular comment fields. They already ignore ITUNES_CDDB_IDS and ITUNNORM, just need them to ignore ITUNPGAP and ITUNSMPB also.

I will post here the conclusion of my conversation with them.

gerph
2006-11-16, 04:55
Many thnaks for all your hard work on this Gerph.

<smile> It's no big deal; I enjoy playing with the ID3 bits, even if frustrations like iTunes do spoil the fun a little.


I guess "corruption" was perhaps too strong a word, but when this stuff first popped up in SlimServer it looked like garbage to me. Now I understand that it is legitimate data as far as iTunes is concerned, albeit it could perhaps have been recorded in a better place.
FYI: I am using SlimServer version 6.5.1 - 10638 - Windows XP - EN - cp1252.

Since I'm unlikely to be able to persuade Apple to move from ID3v2.2 to v2.3 too quickly, I guess my best bet is to ask those nice guys at Slim if they could get their software to ignore these particular comment fields. They already ignore ITUNES_CDDB_IDS and ITUNNORM, just need them to ignore ITUNPGAP and ITUNSMPB also.

I will post here the conclusion of my conversation with them.

I looked at updating the code in the MP3::Info last night after posting but unfortunately my eyes were giving up at that point and I decided to call it a night. I might have a look again today, but if Slim are already on it then there's no point in duplicating effort.

Tradewind25
2006-11-16, 05:09
...but if Slim are already on it then there's no point in duplicating effort.

I've emailed Slim, and included our conclusions (thanks largely to your efforts). I have suggested that SlimServer ignore ITUNPGAP and ITUNSMPB, as it already does ITUNES_CDDB_IDS, ITUNNORM. Waiting a response.

radish
2006-11-16, 07:49
You'd be much better off raising an enhancement request over at http://bugs.slimdevices.com, then any one of the devs can pick it up and fix it.

Tradewind25
2006-11-16, 16:54
Bug 4513 has been logged.

Tradewind25
2006-11-18, 10:24
Bug 4513 has been logged.
Workaround.

Pending a fix to this bug, there is a workaround :

Use the freeware utility MP3Tag (see http://www.pm3tag.de) to edit the MP3 files and remove the COMMent frames containing the ITUNPGAP & ITUNSMPB fields in their entirety. Note that this edit can be run on multiple files simultaneously. So, if you go into MP3Tag and change directory to the iTunes Music folder then you can remove the offending Comments from all iTunes-ripped files all at once. (This doesn’t seem to upset the playing of the tracks through iTunes, should you so wish.)

gerph
2006-11-19, 09:48
Workaround.

Pending a fix to this bug, there is a workaround :

Use the freeware utility MP3Tag (see http://www.pm3tag.de) to edit the MP3 files and remove the COMMent frames containing the ITUNPGAP & ITUNSMPB fields in their entirety. Note that this edit can be run on multiple files simultaneously. So, if you go into MP3Tag and change directory to the iTunes Music folder then you can remove the offending Comments from all iTunes-ripped files all at once. (This doesn’t seem to upset the playing of the tracks through iTunes, should you so wish.)

Obviously you can do that, or use any of the other editors that supports ID3v2.2 to do so. This isn't an editor I'd heard of - typo in the URL above, btw http://www.mp3tag.de/ - so I thought I'd try it out. It seems to work quite well.

I'm a little unsure why ID3v2 editors - this one included - seem to insist on capitalising the comment description names. They are case insensitive and as such iTunNORM and ITUNNORM are different comment frames and both are allowed within the same file.

These observations do not affect the status of the original report and only refer to the operation of this particular application.

Tradewind25
2007-02-11, 05:46
Bug 4513 has been logged.

Issue is fixed in change 11374.

joebowbeer
2007-07-14, 13:43
Correction: mp3 tag editor link mentioned in workaround is

http://www.mp3tag.de/

Also note that the fix is not scheduled to be released until version 7.0.

deeswee
2010-09-07, 02:42
The file description is corrupted. Genre, Artist, Album are corrupted. Comment is removed and replaced with iTunPGAP, so if, like me, you've listened to a lecture and meditation mp3 and added comments to say what the talk is about and when the meditation starts, those are GONE - much time wasted! Sure, the audio part is not corrupted, but the rest IS!

Nonreality
2010-09-09, 00:22
The main thing is not to let Itunes mess with your tags. Soundcheck is the usual culprit. It seems that the last couple of versions of Itunes don't seem to write gap info to the tags now. Soundcheck will.