Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BCPalmer]

Hey all,
I noticed that if I have an MP3 file that I tag with the track field set to 32, it will show up again later as zero '0' if I clear my library and re-import my files.  If I right click the file and select properties in a standard WindowsXP window and go to tab 3, Windows properties reports the track tag as being set to 32.  Granted, no one typically re-imports their library, but I thought I'd report it none the less.  I just reproduced the problem by taking an MP3 file, bringing up its properties, setting track to 32, saved, cleared library, and imported all media files.  Any files that have a track number of 32 came back up with a track number of '0' zero.  Thanks!!!
ver 8.0.388

Brian Palmer

[xen-uno]

I forgot why MJ does this, but it's been covered b4. Do a forum search for related posts, "track number" may be a good search string.

Xenno

[Tolga]

I wish MJ had a switch not to do this.

[KingSparta]

the answer you seek can be found on http://www.Xfiles.com

or you can use the search option in the forum for the answer.

[Nick_LeFave]

I never did get a satisfying answer back when I posted my question.

Is this something that MJ can work around or fix?

Thanks

[dlbarron]

I've asked this same question, along with others, and the only response I've seen is that this is a known bug in MJ.  It has something to do with the number of bytes used to store a track number being 32 and any track number of 32 gets interpreted by MJ as being 0, or some such thing.
The upshot is, this is a known problem but no one seems to know if it will ever be fixed.  BTW, MMJB and WinAmp don't have this problem.

[KingSparta]

well what it is, is (space) = Ascii (32)

and if there is a space in the id3v1 tag in the comment field at len(30) then 32 would always show up.

since Id3v1 does not have a track# it would always showup wrong.

Id3v1.1 added the track#, but used the last 2 chrs of the comment field. thats why you can really only put 28 chrs in a id3v1.1 comment field, and 30 chrs in a id3v1 comment field.

take in mind most cd's do not have 32 tracks so this problem normaly does not show up.

so to sort of fix the problem J river (matt i think) decided to convert the space normaly found in the track# area to 0

as was said before this has been commented on before

[xen-uno]

And if you use ID3v2 tags only then u won't encounter the problem at all.

edit> Nevermind previous, does it with v2 tags also.

JRiver: How about having MJ detect what tag version file has (v1 or v2). If v1 then leave as it is now. If V2 (or v1 AND v2) have it handle the number 32 correctly (no zeroing).

[KingSparta]

they can't win no matter what they do.

but that said, this problem only shows up on MJ and not on other jukebox programs.

i think it is because the detect chr 29 in the comment field if that = zero byte then track number follows and the id3v is id3v1.1 if no zero byte then it must be version id3v1

[BCPalmer]

Hey all,
Thanks for all the info.

Just for my own curiosity, when importing files to the library, does MJ read both the ID3V1 and ID3V2 tags?  And if so, since MJ seems to record the track info correctly in the ID3V2 tag, have what's in the ID3V2 tag over ride the ID3V1 information (if it doesn't already).  The only reason I mention this is, again, right clicking the mp3 file and selecting properties (in WinXP) then going to tab 3 (Summary) you can see the track number.  However, I do not know what version of the ID3 tags Windows supports.  Could be V1.1 or V2.  Thanks again everybody!!!

Brian Palmer