[X] Problem with leading zeros in the TRACK tag Options

[LikeYourStyle]

Hi Florian,

Firstly... mp3tag is a great product. I love it.

I am creating a set of audio files with 3 digit track numbers in the file names.

mp3tag creates ID3v2.3 tags with a track of 028, 029, 030, 031 etc.

However, when I view these resulting tagged files in Windows Explorer and Windows Media Player the above track numbers are shown as 28, 29, 24, 25.

So, Windows is interpreting tag 030 as 24 and tag 031 as 25

So far I have files with track numbers in the range 001 to 053 and it appears that 001 to 009 work fine but after that the only track tags that Windows interprets correctly are 018, 019, 028, 029, 038, 039 & 048, 049.

If I remove the leading zero by editing the file name, it solves the problem but that will cause my files to be displayed in the wrong order.

I can also solve the problem by manually removing the leading zero in mp3tag after the filename has been converted into tags but that does away with a lot of the benefit of your very good Filename to Tag utility.

It is clear to me that this leading zero in the actual tagged field is causing problems with the algorithm that windows uses to "calculate" the track numbers.

Is it possible for you to strip leading blanks when converting the track number in the file name into the TRACK tag so that they are actually stored as 28, 29, 30 and 31.

For info, I am running Windows 7 Ultimate 64 bit.

[DetlevD]

... I am creating a set of audio files with 3 digit track numbers in the file names. mp3tag creates ID3v2.3 tags with a track of 028, 029, 030, 031 etc. However, when I view these resulting tagged files in Windows Explorer and Windows Media Player the above track numbers are shown as 28, 29, 24, 25. So, Windows is interpreting tag 030 as 24 and tag 031 as 25. ... If I remove the leading zero by editing the file name, it solves the problem but that will cause my files to be displayed in the wrong order. ... It is clear to me that this leading zero in the actual tagged field is causing problems with the algorithm that windows uses to "calculate" the track numbers. ...For info, I am running Windows 7 Ultimate 64 bit.

We have already noted this phenomenon.
http://forums.mp3tag.de/index.php?showtopic=13211

The problem seems not related to Mp3tag but to other software on the target system.
Numbers resp. number strings (!), which contain only digits from 0 to 7 and begin with 0, are interpreted as octal numbers by the other software.
Do deeper search into this direction.

The ID3 standard for ID3v2.3 and ID3v2.4 says:
TRCK
The 'Track number/Position in set' frame is a numeric string
containing the order number of the audio-file on its original
recording. This MAY be extended with a "/" character and a numeric
string containing the total number of tracks/elements on the original
recording. E.g. "4/9".

So the Mp3tag tag-field TRACK (ID3 TRCK) contains a 'numeric string', not an octal number.
You can verify this with a hex editor for yourself.

... Is it possible for you to strip leading blanks when converting the track number in the file name into the TRACK tag so that they are actually stored as 28, 29, 30 and 31. ...

Bewildering ... do you mean leading blanks or leading zeros?

Are you aware of the Mp3tag scripting functions?
The $num(<number>,<width>) may be of help to format a number as needed.

DD.20120120.0552.CET

[LikeYourStyle]

...

The problem seems not related to Mp3tag but to other software on the target system.
Numbers resp. number strings (!), which contain only digits from 0 to 7 and begin with 0, are interpreted as octal numbers by the other software.

...

do you mean leading blanks or leading zeros?

Are you aware of the Mp3tag scripting functions?
The $num(<number>,<width>) may be of help to format a number as needed.

DD.20120120.0552.CET

Thanks DetLevD.

I did of course mean strip leading zeros. I have now had a look at the scripting functions. Unfortunately, they are not available when converting filenames to tags. However, I have worked out an easy solution to my problem:

My filenames have the format

aaa - bbb .nnn.ccc
where aaa = artist, bbb = album, nnn = track, ccc = title

I was using the transformation
%artist% - %album% .%track%.%title%

This was producing a 3 digit track with leading zeros and Windows explorer was misinterpreting most numbers between 010 to 077 as hex (as you said).

The simple solution was to set up a new transformation for use with numbers 010 to 099.
%artist% - %album% .0%track%.%title%

This transformation generates 2 digit track numbers by ignoring the leading zero and so avoids the problem with Hex numbers (which I have also seen in some Android apps).

[DetlevD]

... This was producing a 3 digit track with leading zeros and Windows explorer was misinterpreting most numbers between 010 to 077 as hex (as you said). ...

No, I did not say hexadecimal, but octal.
http://en.wikipedia.org/wiki/Octal

... The simple solution was to set up a new transformation for use with numbers 010 to 099.
%artist% - %album% .0%track%.%title%
This transformation generates 2 digit track numbers by ignoring the leading zero and so avoids the problem with Hex numbers (which I have also seen in some Android apps).

Ok, this is one way to go, but needs to do it by two filtered steps.
Another way to go would be to modify the tag-field TRACK, after importing the number string having the leading zero, by an action "Format value" using the format string: $num(%TRACK%,1).

DD.20120120.1444.CET

[mnuman]

For this purpose, I've added a custom conversion action to the menu name "De-oct TRACK numbers". It consists of a replace value with regular expression on the TRACK field. The regular expression is "^0+([1-9]\d*)", the replace value is $1. I am looking for a pattern starting of a number of leading zeroes followed by a single non-zero digit, followed by any number of digits (including zeroes). The parentheses serve to "save" the matched pattern into the buffer 1, that is later recalled by $1.
Anyway, if you're really interested in regexp syntax: there are a lot of resources if you google ...

Hope this helps,

Milco

This post has been edited by mnuman: Mar 8 2012, 17:01