IPB

Welcome Guest ( Log In | Register )

> Notice!

Please take a minute to check our Frequently Asked Questions. Use Search to reveal possible related topics.

Also make sure you've read the Forum Guidelines before posting in this forum.

 
Reply to this topicStart new topic
> Padding Track Num, Scrambled., Does padding track # cause problems with explorer or the file attrib.?
Drifter
post Mar 18 2011, 05:01
Post #1


Member


Group: Members
Posts: 4
Joined: 18-March 11
Member No.: 14039
Mp3tag Version: V2.48



Does padding of the track numbers affect how explorer and mp3 players reads the track number?(Padding being the prefixing with zeros to have a specific number of characters.)

I used 'Bulk Rename Utility' ver 2.7.1.2 to rename a series of 150 mp3s that were named with the suffix of 'title disk_track'; 01_01 through 15_10 to their sequential counterparts 001 through 150.
The conversion worked and everything was fine. I then attempted to use mp3tag to cleanup the file attributes and set the track as the last three characters of the filename.
Using Action with a sort by filename: Format value "TRACK":$right(%_filename%, 3)
This worked fine within mp3tag, when refreshing, reloading the directory, reloading the program, rebooting. It all appears fine within the program. Looking at the file attributes in explorer they are scattered hitter and yon, and less than 1/2 of the filename suffixes appear to match the track number. (Is this clear enough or would an image help clarification?)

I feel safer with 01 than 1 in the case of alphabetical sorts but is this my problem?

Any suggestions?
Thank You.
Attached thumbnail(s)
Attached Image
 
Go to the top of the page
 
+Quote Post
Drifter
post Mar 18 2011, 05:20
Post #2


Member


Group: Members
Posts: 4
Joined: 18-March 11
Member No.: 14039
Mp3tag Version: V2.48



QUOTE (Drifter @ Mar 18 2011, 05:01) *
Does padding of the track numbers affect how explorer and mp3 players reads the track number?(Padding being the prefixing with zeros to have a specific number of characters.)
I feel safer with 01 than 1 in the case of alphabetical sorts but is this my problem?


There was a post from March of 2010; don't remember much but he had his tracks padded to 2 characters. He didn't find a satisfactory answer in that post but I think his problem was related, messed up track number read in explorer.

More recently, LifesSweetDrug asked for a method of stripping the leading zero from tracks and dano answered.

Action type: Format value
Field: TRACK
Formatstring: [$num(%track%,1)]

and a varient for 10-99

But this leaded to the discovery of the tool autonumber wizard... and it's option of Leading zeros for tracknumbers.

It turns out explorer doesn't like padding of the track number field, discovered by experimentation.

Thank You.

This answers the problem.

But why does explorer reject the padding?
Go to the top of the page
 
+Quote Post
DetlevD
post Mar 18 2011, 05:24
Post #3


Member


Group: Full Members
Posts: 5031
Joined: 26-May 06
From: Wuppertal, Germany, Planet Earth
Member No.: 3194
Mp3tag Version: 2.63



QUOTE (Drifter @ Mar 18 2011, 05:01) *
Does padding of the track numbers affect how explorer and mp3 players reads the track number?(Padding being the prefixing with zeros to have a specific number of characters.) ...

Maybe.

Hmm, few days ago there was a rather similar request like yours now.
Looking at your pictures all looks fine with focus to the filenames.

When looking at the property sheet of a file resp. at the property column titled "#" there are the quirks.

For me ... it looks like ... if numbers with one leading zero will be interpreted as "octal numbers".
So that the octal number "010" will be displayed as decimal "8" or octal number "011" will be displayed as decimal "9".

I have no definite explanation for this phenomenon, but I tend to say that the property handler has a bug when reading the TRACK tag field's number string and the string looks like an octal coded number.

But that such an error, before software deployment, at least in the final inspection, has not be noticed to anyone of the programmers, that would be unbelievable.

Better you check the tag type of your files.
For compatibility with Windows they should have tag type ID3v2.3 UTF-16.

DD.20110318.0540.CET

This post has been edited by DetlevD: Mar 18 2011, 05:44


--------------------
* Beyond that, don't ask, when you don't know what to do with the answer. *
♥ home is where the heart is ♥
Go to the top of the page
 
+Quote Post
Drifter
post Mar 18 2011, 06:13
Post #4


Member


Group: Members
Posts: 4
Joined: 18-March 11
Member No.: 14039
Mp3tag Version: V2.48



QUOTE (DetlevD @ Mar 18 2011, 05:24) *
"... property sheet of a file resp. at the property column titled "#" there are the quirks.

For me ... it looks like ... if numbers with one leading zero will be interpreted as "octal numbers".
So that the octal number "010" will be displayed as decimal "8" or octal number "011" will be displayed as decimal "9".

I have no definite explanation for this phenomenon, but I tend to say that the property handler has a bug when reading the TRACK tag field's number string and the string looks like an octal coded number.

But that such an error, before software deployment, in the final inspection, has not be noticed to anyone of the programmers, that would be unbelievable.


While trying to get my head around the concept I ran a few statistics that might be of interest.

Tracks Doubled in Explorer with Leading Zero
8,9,18,19,28,29,38,39,48,49,58,59
(24 Tracks Doubled)

Tracks 64-67 and 71-77 (inclusive) are Missing
(12 Tracks Missing)

Tracks above 78 (inclusive) are intact.
(73 tracks at high end)

The first grouping only files ending in 8 or 9 are doubled. There is definitely a pattern.

Track #'s are sequential with the insertion of the duplicates at there correct location, the tracks will continue counting until the next filename ending in 8 or 9 where another duplicate will be inserted.

REM edit: strike duplicate(s) and insert octal-pair, duplicate implies that it is the second or was copied from something that came before whereas octal-pair is just trying to describe numbers ending in 8 and 9. Numbers that have no place in an octal system. Although this description works up to 63, I haven't managed to fit the missing numbers into the system of numbers, nor why tracks in the ten's place (eight's in octal?) are unaffected.

Either mp3tager reads an writes tracks in a unique way or there is a problem with explorer of Win7 32 or MSWin ver6.1.7601. (I will compare this with a win7 64bit machine tomorrow, as it is late.)

Thank You DetlevD.

Just because this post needs one more concept to be confused about:
Nonary is a base- numeral system, typically using the digits 0-8, but not the digit 9.
Go to the top of the page
 
+Quote Post
Drifter
post Mar 18 2011, 06:42
Post #5


Member


Group: Members
Posts: 4
Joined: 18-March 11
Member No.: 14039
Mp3tag Version: V2.48



QUOTE
Hmm, few days ago there was a rather similar request like yours now.

Managed to track down that post, thanks for the pointer.

herby-t posted it on March 13,2011 (in german)
http://forums.mp3tag.de/index.php?showtopic=13211

somenick and dano were discussing UTF-8 and unicode support which might be related, I'll try and unravel that latter.

QUOTE
For compatibility with Windows they should have tag type ID3v2.3 UTF-16.


If you are refering to mp3tag Options > Tags >
it looks right to me. I'll do some reading on ID3 and related to gain a better understanding.

Thank You and Good Night.
Go to the top of the page
 
+Quote Post
JeffWilliams
post Mar 6 2014, 03:04
Post #6


Member


Group: Members
Posts: 1
Joined: 6-March 14
Member No.: 19189
Mp3tag Version: 2.58



I greatly thank all involved for looking into this problem. Last Friday I changed from Windows XP to Win 7 and have been having nothing but headaches with this same track numbering issue. For years I have been using the defunct original ID3 and inserting leading zeros as they were needed by earlier Windows Explorer & Media Player to properly set the tracks. They are also useful in track naming for proper sorting.

Now I find that the leading zeros cause problems with Windows 7 Explorer (at least in my Win 7 Pro 64-bit version). Renumbering the tracks without any leading zeros appears to have solved the problem completely.

Previous to finding this solution, I had tried repeatedly to fix the track numbering, using my old standard ID3, NCH's StampID3, and your Mp3tag, all without success. Renumbering 2 different audiobook folders (180 files and 173 files) without leading zeros fixed both immediately upon saving the changes.

So far as I can tell, this site is the only one to address this problem directly, much less to have offered a working solution. Again, THANK YOU!!



QUOTE (Drifter @ Mar 18 2011, 07:42) *
Managed to track down that post, thanks for the pointer.

herby-t posted it on March 13,2011 (in german)
http://forums.mp3tag.de/index.php?showtopic=13211

somenick and dano were discussing UTF-8 and unicode support which might be related, I'll try and unravel that latter.



If you are refering to mp3tag Options > Tags >
it looks right to me. I'll do some reading on ID3 and related to gain a better understanding.

Thank You and Good Night.

Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 31st October 2014 - 15:18