1170 Disc# and Track# fields incorrectly padded in masks

[chrisjj]

Masks <Disc#> and <Track#> are supposed to write the field values, but instead to single-digit values they add a zero to the left.

Workaround: none unknown. <Track#:1> fails to preserve values such as 01.

[Peke]

Masks <Disc#> and <Track#> default values are Masks <Disc#:2> and <Track#:2>, <Disc#:1> <Track#:1> should work for Conditional Masks
using $If(<Track#>>9,<Track#:2>,<Track#:1>)

Edit: And even complexed one $If(<Track#>>9,$If(<Track#>>99,<Track#:3>,<Track#:2>),<Track#:1>) and so on...

[chrisjj]

Masks <Disc#> and <Track#> default values are Masks <Disc#:2> and <Track#:2>

That fails to accord with docs.

<Disc#:1> <Track#:1> should work for Conditional Masks
using $If(<Track#>>9,<Track#:2>,<Track#:1>)

Thanks, but that's not necessarily the field value. Is there any way to get field value - 1, 01, 1/1 or whatever - without it being changed by MM?

[jiri]

You are right, it was ok in MM 2.5, but since MM 3.0 can handle non-numeric track# (including leading zeroes), the current approach is a little limited. It will be fixed.

Jiri

[chrisjj]

Meaning <Track#> and <Disc#> will deliver true field values?

[jiri]

Exactly.

[chrisjj]

Great - thanks.

[Teknojnky]

This change is a problem. Windows displays files by text not numerically, that is the whole reason tracks were padded in the first place.

Now I can understand discs should not necessarily be padded, because in most cases there are usually not having 10 disc sets.

But the track# should remain padded (and yes I understand that :2 can be added to pad).

edit:
grrr, I don't like it, but I can see that this behavior might required to support where track#/total are used in the track/disc fields.

Now I have go and change a dozen organize masks..

edit2 :

no no no noooooooooo

this has totally sdkjfskjfd my masks up in regards to triple digit masks.

I can't globally use track#:2 because I use 3 digits to indicate disc + track number..

ie 101 = disc 1 track 1.

I am not happy.

[chrisjj]

Windows displays files by text not numerically

Not reproduced here. E.g. in Win XP Explorer:

Code: Select all

01 Union Civica.mp3
2 Jueves.mp3
03 Ataniche.mp3

Now I can understand discs should not necessarily be padded, because in most cases there are usually not having 10 disc sets.

I would not like MM to sort my 2-disc sets one way and my 10-disc sets another.

grrr, I don't like it, but I can see that this behavior might required to support where track#/total are used in the track/disc fields.

What's with "might", TJ? ;)

Now I have go and change a dozen organize masks.

Sympathies. But that's the price of relying on contra-doc behaviour! ;)

Seriously though, because this change will cause incompatibility with older versions, I do hope the Devs will include alert users upon the affected release.

[rusty]

If anyone has any bright ideas to satisfy all needs, bring 'em on.

(I personally liked the 'old' approach with padding, but agree that it was confusing/inconsistent/problematic for users who didn't want the padding.)

-Rusty

[chrisjj]

If anyone has any bright ideas to satisfy all needs, bring 'em on.

Re the specific issue of whether the default pads or not, I think by definition no solution can satisfy all needs since they are contradictory. Re the issue of delivering /options/ that satisfy all needs, then surely the current design (and proposed implementation) is fine.

[Seeker]

Well, whether I like it or not, now it is "right".

Padding anything behind the scenes (even if it is intended to help) is really breaking the rules set for how these masks work.

I took advantage of it myself - my disc #s were single digit, and I liked how it added a 0 in front.

But "it was wrong". When the fix came, I used a script to make each numeric disc # to have a 0 within it. (I did it this way because I have non numeric fields like A B and even "Image Album" in the Disc #.

So, yes it is a pain both for tracks and disc #s - but I think we all need to belly up to the bar and fix our own masks or pad our tracks with 0s ourselves . We took advantage of the "wrong" way to do it.

[Teknojnky]

a simple option to automatically pad track and/or disc numbers (during auto-organize) would be fine. Basically allow choosing of old behavior and new bahavior.. noting to the user that new behavior supports text/non-numeric track/disc fields where as the old behavior is more limited.

I am still thinking about it, but I can't see any simple way to achieve work arounds (file masks) to the previous behavior while keeping the new.

[Teknojnky]

Well, whether I like it or not, now it is "right".

Padding anything behind the scenes (even if it is intended to help) is really breaking the rules set for how these masks work.

I took advantage of it myself - my disc #s were single digit, and I liked how it added a 0 in front.

But "it was wrong". When the fix came, I used a script to make each numeric disc # to have a 0 within it. (I did it this way because I have non numeric fields like A B and even "Image Album" in the Disc #.

So, yes it is a pain both for tracks and disc #s - but I think we all need to belly up to the bar and fix our own masks or pad our tracks with 0s ourselves . We took advantage of the "wrong" way to do it.

I agree somewhat.

What I want is for tracks to be on the file system PADDED, but displayed in the track list without padding.

I don't really care if the UI hides the zeros in the fields, or if the auto-organize pads the zeros, but I would just rather not have to go and re-do a bunch of masks (and fix a bunch of data) because of this bakcwards change or 'fix'.

[Seeker]

As always, when two ways of doing things are diametrically opposed, we're back to a checkbox option for how something should act - and I think you said that yourself.

But the fact it was "backward fixed" as you said, doesn't change the fact that simply undoing the fix would make it wrong - even if we liked it wrong. The person who reported it and the person who fixed it did the right thing.

But maybe we need a clickbox to say "do it wrong - I'm used to it that way" in addition to it being correct now.