V13.5.0.2 Bug: [track] can deliver wrong string value

[chrisjj]

When WMA metadata item "TrackNumber" is a single-digit value, dBpa [track] is inaccurate - it adds a leading zero e.g.:



Anyone know a workaround in dBpa programmatic naming? Thanks.

Current best workaround here: afterward, fixup the track value using Mp3tag.

[Spoon]

Re: V13.5.0.2 Bug: [track] can deliver wrong string value

By design we pad the track number, for th next R15 beta I will add the ability to get rid of track padding in filename.

[chrisjj]

Re: V13.5.0.2 Bug: [track] can deliver wrong string value

By design we pad the track number

Can't imagine why!

for th next R15 beta I will add the ability to get rid of track padding in filename.

Thanks. Can I suggest also the docs carry a warning about the default behaviour.

[Spoon]

Re: V13.5.0.2 Bug: [track] can deliver wrong string value

People use filenames to alphabetic sort, if there is :

2 xxxx
10 xxx

then track 10 will be listed before track 2 without padding

[chrisjj]

Re: V13.5.0.2 Bug: [track] can deliver wrong string value

Sounds like a good case for e.g. [paddedtrack] (where track numbers are less than 100).

But not a good case for inaccuracy of [track].

[chrisjj]

Re: V13.5.0.2 Bug: [track] can deliver wrong string value

for th next R15 beta I will add the ability to get rid of track padding in filename.

Did this happen?

[chrisjj]

Re: V13.5.0.2 Bug: [track] can deliver wrong string value

Did this happen?

FTR it seems no, but the feature did appear in R16 https://www.dbpoweramp.com/Version-Changes-DMC.htm .