Bugzilla – Bug 4513
SlimServer should ignore the iTunes COMMENTs: ITUNPGAP & ITUNSMPB
Last modified: 2008-12-18 11:12:53 UTC
Symptoms ========= When you rip a track via iTunes 7 and encode as MP3, fields with the following keywords are included in the COMMENTs frame of the ID3 tag stored in the .mp3 file: ITUNES_CDDB, ITUNNORM, ITUNPGAP, and ITUNSMPB. (NOTE: these are not seen in the "iTunes Music Library.xml" file.) Once this track has been scanned into SlimServer, the Song Info displayed (either via the web UI or on the Squeezebox) includes the ITUNPGAP and ITUNSMPB fields as "real" comments. They are then followed by any user-entered comments. On the other hand, the ITUNES_CDDB and ITUNNORM fileds are ignored. Note: Since the ITUNSMPB field contains 156 hex characters this is particularly irksome if you want to get to the real comments stored against the track. Suggested Fix ============= The ITUNPGAP & ITUNSMPB fields should also be supressed when displaying track Comments on SlimServer/Squeezebox. They are not true comments but are specific to the iTunes player. I believe that they relate to the gapless playback feature of iTunes 7. Version Info ============ iTunes 7.0.2 SlimServer 6.5.1 - 10638 - Windows XP - EN - cp1252 Sample Files ============ Black_Muddy_River.mp3 - a sample file ripped using iTunes 7. Tag.doc - contains 2 screenshots: a) the Song Info as displayed by SlimServer (note the Comments data) b) the output of the ID3Tag editor utility showing the tag embedded within Black_Muddy_River.mp3. (I would be grateful if you could tell me to where I may upload these files for your perusal.) Geoff Johnson
Created attachment 1716 [details] MP3 file produced by iTunes 7
Created attachment 1717 [details] Screenshots.
I have changed the Severity of this from "enhancement" to "normal" as I believe this to be a bug rather than an enhancement request; for the following reasons: a) We already ignore some of Apple's "private" data which they store in the Comments frame of their (v2.2) ID3 tag i.e. the ITUNES_CDDB and ITUNNORM fileds. b) This bug makes the viewing of Comments on the Squeezebox virtually unusable, since you have to wait for a mass of garbage to scroll past before reaching your real comments (perhaps just a word or two). Thx.
Created attachment 1718 [details] Tentative patch to remove iTunes comments from track details This is just a tentative patch for fixing the problem. It's been run but not tested against the exact MP3s that are a problem. I've placed the change in the Schema/Track.pm file, alongside the iTunes_CDDB change and the SoundJam_CDDB change. My personal opinion is that this is the wrong place for these changes - they should really be at the ID3v2 decoding level, rather than the Schema level. However this is a far simpler patch and it's likely that my understanding that leads me to think that it's in the wrong place is flawed. The patch actually checks for iTun???? where ? is a letter A-Z. This will catch the iTunPGAP, iTunNORM, and iTunSMPB comment blocks and (I would hope) any future comments that use the same form.
this is a developer tool. developers can and will change settings to help organise the bugs. This does NOT affect time to implementation in any bad way. Enhancement simply means it is new code for a new thing. these iTunes comments are NEW, thus could not be in the design. SS still works as designed so you are just working to get in the way. not a good idea. however, it does serve to make people like me have no more interest in helping people like you. take that as it is. I'm sure someone else will be happy to test and merge the patch so helpfully supplied by justin.
(In reply to comment #5) > this is a developer tool. developers can and will change settings to help > organise the bugs. This does NOT affect time to implementation in any bad way. > Enhancement simply means it is new code for a new thing. these iTunes > comments are NEW, thus could not be in the design. SS still works as designed > so you are just working to get in the way. not a good idea. > however, it does serve to make people like me have no more interest in helping > people like you. take that as it is. > I'm sure someone else will be happy to test and merge the patch so helpfully > supplied by justin. Hey, guys, I never intended to upset anyone in changing the severity of this bug. Please accept my apologies, but I am very new to bugzilla, this being the first bug that I have logged. Clearly I misunderstood the procedure. With other software with which I am familiar, categorising a "bug" as an "enhancement" has an extremely detrimental effect on the "time to fix". Believe me, it was never my intention "...to get in the way...".
what features are ITUNPGAP & ITUNSMPB intended for? might they need to be recorded or is this just more itunes garbage that they thrust on others with each new "upgrade"?
(In reply to comment #7) > what features are ITUNPGAP & ITUNSMPB intended for? > might they need to be recorded or is this just more itunes garbage that they > thrust on others with each new "upgrade"? My understanding is that these relate to the iTunes 7 Gapless Playback feature.
Steven could you see if you can learn anything about these tags, what they are for, and especially if we ought to be paying attention to them in some way, or if we should just ignore them?
The iTunes comment tag "iTunPGAP" is a flag that sets the "Part of a gapless album" option on or off in iTunes. This tag is used to disable crossfade playback in iTunes of said track regardless of the crossfade setting in iTunes. Since we do our own crossfade detection I feel we can ignore this one completely. The iTunes comment tag "iTunSMPB" contains iTunes gapless playback information. If it is possible to decipher this tags information we could possibly use it for gapless Squeezebox/Transporter playback as well. I feel it should be ignored for the comment tag however.
Chris, should this go back to you?
What are the values for these parameters, do you know? Are they like numbers in seconds or some other encoding?
Looks like they are complete lines, so they could be parsed out in the same way we do in Utils::SoundCheck for iTunNORM. Except for these two, we'll just dump the data into the bitbucket. I can probably take this one, but would need to know which is preferred for where to handle the change. Slim::Utils::SoundCheck (where we are already processing another iTunes comment) or as a second process to parse and splice within MP3::Info iteself, so the unwanted comment items are never returned from getTag.
"iTunPGAP" is just a value of 1 or 0 representing on or off. "iTunSMPB" on the other hand is a string of numbers that looks similar to the "iTunNORM" value but longer. Here is an example string for reference: " 00000000 00000210 00000840 0000000000BFD330 00000000 00685706 00000000 00000000 00000000 00000000 00000000 00000000" This link has some information on deciphering the numbers: http://www.hydrogenaudio.org/forums/index.php?showtopic=48231&st=136#
Created attachment 1811 [details] more complete patch Per Dan, I've moved the stripping of unneeded comments into _preCheckAttributes, so that it's handled before the insertion to the DB. We can't really put this into the ID3 parsing as that is intended as a more generic module, rather than strictly for SlimServer use. Others may want to have the comments available. Dan, let me know if you feel this patch is good enough to merge in.
fixed in change 11374
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.