[X] Problem with leading zeros in the TRACK tag

[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.
/t/11709/1

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(,) 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(,) 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

[DetlevD]

For this purpose, I've added a custom conversion action to the menu name "De-oct TRACK numbers". ...

Following scripting expressions remove leading zeroes from the tag-field TRACK ...

$regexp(%TRACK%,'^0+([1-9]\d*)','$1') $regexp(%TRACK%,'^0+(\d+)','$1') $trimLeft(%TRACK%,'0') $num(%TRACK%,1)

DD.20150101.1913.CET

[ohrenkino]

Following scripting expressions remove leading zeroes ...
...

As you dug up an old thread from 2012 the code aspects are certainly true, yet, they do not solve the underlying problem why one could possibly want leading zeros in the first place.
Usually, you add them to get the correct padding as WE in general does not sort numerically but alphabetically.
If the sorting were numerical, you wouldn't find the 1, 10 and 100 next to each other.
If you have folders with a lot of files, e.g. those of an audio book, then it could very well be that you need padding for 3 digits.
Problem is, that right now the bad octal bug hits.
So in my opinion the only way to get around this problem is not to use the track number as the first piece of data in a filename.
You could either rename your files with the album or artist as first data or introduce a character that makes WE treat the filename as a string, e.g. my favoured underscore. Then follows the three-digit track number, e.g.
_001 - My file
should lead to a correct sorting order.
This procedure would not make use of the presented code, though.

[DetlevD]

... leading zeros in the first place.
Usually, you add them to get the correct padding as WE in general does not sort numerically but alphabetically. ...

Isn't it so that the 'octal problem' affects only the tag-field TRACK?
The Windows Explorer property manager takes a numerical value having a leading '0' as an octal number.
Maybe the property manager takes a numerical value having a leading 'x' as a hexadecimal number?
I don't know.
A name in the file system can have leading zeroes as you will.

There seems to be a problem with the standard sorting algorithm (binary, alphabetically, naturally), ...
but this can be adapted ...
http://maximumpcguides.com/windows-7/turn-...ndows-explorer/
https://social.technet.microsoft.com/Forums...nt-alphabetical

DD.20150101.2109.CET