Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Inconsistency in subsong indexing (Read 1990 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Inconsistency in subsong indexing

Using %subsong% on cuesheet track, returns track index enumerated for 1. This is as expected.

On mp4, ogg, opus,... with chapters, subsong index returned starts with 0, which is inconsistent with above and with the enumeration in referenced track itself, as these chapters inside referenced file are enumerated from 1.

Inconsistency in subsong indexing

Reply #1 –
So what? I don't see a problem with this. The subsong indices can be pretty much anything. They don't even need to be consecutive. Of course, the best reason for keeping things as they are is that changing the current behaviour is bound to cause all kinds of confusion because existing playlist/media library/whatever entries would suddenly refer to different tracks after a software update.

Inconsistency in subsong indexing

Reply #2 –
Quote
So what?

If anyone uses this tag gets different track for cuesheets and chapters, and possible non-existing track for chapters

Quote
the best reason for keeping things as they are is that changing the current behaviour is bound to cause all kinds of confusion because existing playlist/media library/whatever entries would suddenly refer to different tracks after a software update.

Which interface would be confused if subsongs are enumerated from 1 (as they actually are in referenced file)?

Inconsistency in subsong indexing

Reply #3 –
Quote from: foosion on
So what? I don't see a problem with this. The subsong indices can be pretty much anything. They don't even need to be consecutive.
The problem is that users are being perfectly reasonable to expect the indices to match any actual indices that exist in the file, but that is not always the case in reality. What’s a valid reason for them to be different? Especially when the pattern isn’t consistent between differing formats?

Quote
Of course, the best reason for keeping things as they are is that changing the current behaviour is bound to cause all kinds of confusion because existing playlist/media library/whatever entries would suddenly refer to different tracks after a software update.
I don’t see how inconvenience to users with subsong indices in playlists – surely something of a minority – justifies maintenance of what seems to be an illogical and inconsistent behaviour. Anyway, the ML can be re-scanned with ease, and playlists might be recoverable automatically with foo_playlist_revive or even with a built-in scanner if this behaviour were to be rectified.

Inconsistency in subsong indexing

Reply #4 –
Unfortunately, the subsong index is not strictly specified as a one-based, sequential index of the tracks within a file. Even more unfortunately, there are some official plugins that use a zero-based subsong index. (I think some of kode54's module decoders even use non-sequential subsong indices as they use the subsong index as an offset into the file.) So what is the reason for these plugins to deviate from the rest? I actually have no idea. My best guess is that at the time of writing using a zero-based index was convenient for the developer and it was not considered that users might want to directly use the subsong index. The subsong index was probably just regarded as an opaque value that uniquely identifies a track within a file.

What would happen now if the plugins in question are modified to use a one-based subsong index? Existing track references, i.e. path-subsong pairs, would suddenly refer to different tracks. For example, assume that subsong 0 refers to the first track, subsong 1 to the second track and subsong N-1 to the last track. If the indexing scheme is changed, subsong 0 refers to a non-existing track, subsong 1 to the first track and there is no pre-existing subsong that refers to the last track.

Where are subsong indices used? Firstly, in the media library and in open playlists. Secondly, in components that associate meta data with tracks but don't store that meta data in the files, for example "custom tagging" components. Thirdly, in FPL playlist files which the user has manually saved: on hard disks, portable storage devices, network shares, CD-Rs, DVDs, maybe even tape backups. This multitude of places makes it very difficult to provide a reasonable migration path. foo_playlist_revive only works for some of the aforementioned cases. Nobody wants to tell users "Some guy on the forum asked us to change the subsong indexing scheme, so when you update to this new foobar2000 version you will lose some of your data." That would be a bad idea.

The bottom line is that I think it would be unreasonable to demand that the subsong index is a one-based sequential index. On the other hand, it would not be unreasonable to ask for an inherent track property that reflects the order of tracks in a file. In fact, I would solve this problem by adding a new technical info item for the decoders in question that contains the one-based index. Let us call it ORDINAL. Then the %subsong% title formatting field could be changed to check for the ORDINAL item and use it instead of the subsong index if it exists.

Inconsistency in subsong indexing

Reply #5 –
Quote from: db1989 on
I don’t see how inconvenience to users with subsong indices in playlists – surely something of a minority – justifies maintenance of what seems to be an illogical and inconsistent behaviour.
Not changing the current, working implementation: zero cost for developers, minor cost (inconvenience) for some users. Code change plus data migration: significant cost for developers (particularly providing tools for migration), significant cost for some more users (including risk of data loss).

Inconsistency in subsong indexing

Reply #6 –
You make it sound very dramatic. I would never have thought that any component by itself cares if subsong starts from 0 or 1, and that all components depend on the state that cuesheet tracks start from 1 and chapter tracks from 0, but they just enumerate what foobar exposes. Maybe it's not like that, but I doubt about described catastrophic impact.

Are you saying that kode's components would break if chapter indexing starts from 1?

Inconsistency in subsong indexing

Reply #7 –
It's not about components, it's about users. Most components don't care at all about subsong indices. However, I think that users would certainly mind if their playlists, custom rating/play count, etc. are suddenly jumbled just because they updated a decoder component. They consequences are definitely not life-threatening, but they are completely unnecessary. As I pointed out there is another approach to satisfy your use case.
 

Inconsistency in subsong indexing

Reply #8 –
OK foosion, perhaps just informing user (updating documentation) is enough. If user is aware that subsongs are usually indexed from 0, and cuesheets from 1, it's not much of a problem to check if track belongs to cuesheet.