Suggestion: Track numbering assistant with start value from 1st file

General Discussion
#1

My suggestion is:
The track numbering assistant should offer an already existing track number in the first file as starting value.
Naturally, the starting value could be overwritten if it does not fit.

The workflow behind it:
when collection podcasts the list of files grows on a regular basis but one never quite knows when it would end.
So you get one file after the other, sometimes more than one file and I like to sort them into the already existing order with an ascending track number.
This usually means that I have to memorize the track number of the last old file, select the new files, open the track number assistant, enter the memorized number and then let the track numbering assistant do what it is supposed to do.

It would ease my frequent tasks if I could select the last file plus the new ones, open the track numbering assistant and get offered the track number from the first selected file. Like that I would not have to memorize it and type it in.

So the basic idea is: use the track number of the first selected file as starting value for the track numbering assistant.
If that number is empty, the starting value would be 1.

#2

I've looked into this and even started experimenting, but it became messy quite quickly. Some observations from my tests:

  1. If the list of files is really a random bunch of files from different sources (e.g., when creating a playlist), the default would then not be the intended case and would require a reset to 1. I can imagine this happening quite often for the auto-numbering assistant often being used in exactly such cases.

  2. If the track number offset would have this behavior, it would also be required for the disc number. Not a problem per se, but it's less obvious.

  3. It gets more difficult when writing the total number of tracks is also enabled. Normally, the field is pre-filled with the number of selected files. But according to the suggested behavior, it would need to be also adjusted by the track offset. If the suggested offset is not intended, the user would have to change two values. Not ideal.

All in all, I'm very hesitant to implement this, although I already made changes internally to allow for this. I can really see who it would benefit your particular use case, but I'm not so sure if it would be a welcome change in general.

#3

I see. I probably stepped into the same trap as other users when they suggest a new behaviour/feature: I only looked at my (special) workflow.
Thank you for taking the effort of such a thorough analysis.

1 Like