cue sheet split limit?

[maxhondur]

Hello,

Just a random thought, as I was using automatic pause detections for my audiobooks: The cue sheet standard supports up to 99 splits per file. Would bumping this number upwards cause instability issues with the current rockbox builds? (I'm using rockbox on the Fuzev1, which to the best of my knowledge ignores index numbers after 99.)

Either way though, sincere thanks to the rockbox team, especially for adding .cue support to begin with

[saratoga]

Hello,

Just a random thought, as I was using automatic pause detections for my audiobooks: The cue sheet standard supports up to 99 splits per file. Would bumping this number upwards cause instability issues with the current rockbox builds? (I'm using rockbox on the Fuzev1, which to the best of my knowledge ignores index numbers after 99.)

Either way though, sincere thanks to the rockbox team, especially for adding .cue support to begin with

From cuesheet.h:

#define MAX_TRACKS 99  /* Max number of tracks in a cuesheet */

Try 100 and see if it works.

[JdGordon]

yeah, changing that #define and recompiling is the only way to do it (and that should be safe), there are surely better ways of doing it than splitting on every pause?

[maxhondur]

saratoga and JdGordon, thank you for the replies.

I split my books into separate files according to chapters, but I figured that internal splits would be kind of cool to have too.. anyways, it was just one of those things that got me wondering. It struck me as an oddity that there was a track limit on a cuesheet in rockbox, considering the intuition that rockbox should be able to handle much more than that, and that the 99 split limit for the cuesheet specification standard seems somewhat arbitrary to begin with.

Again, thanks for the replies. To those who are curious, I've compiled the source code using up to MAX_TRACKS 2000 on the fuze, no apparent problems

[GodEater]

It struck me as an oddity that there was a track limit on a cuesheet in rockbox, considering the intuition that rockbox should be able to handle much more than that, and that the 99 split limit for the cuesheet specification standard seems somewhat arbitrary to begin with.

Resources on an MP3 player are not even remotely close to infinite. Making the change as you have done has robbed your player of memory elsewhere. While you may find that acceptable - others would not. This is why we arbitrarily set the limit at 99, which seems generous in most cases. 2000 seems very excessive to me - but I'm glad you're finding it useful

[froggyman]

It struck me as an oddity that there was a track limit on a cuesheet in rockbox, considering the intuition that rockbox should be able to handle much more than that, and that the 99 split limit for the cuesheet specification standard seems somewhat arbitrary to begin with.

Resources on an MP3 player are not even remotely close to infinite. Making the change as you have done has robbed your player of memory elsewhere. While you may find that acceptable - others would not. This is why we arbitrarily set the limit at 99, which seems generous in most cases. 2000 seems very excessive to me - but I'm glad you're finding it useful

I have never even used the cuesheets, so 99 would be a bit too generous in my case.

[Llorean]

I think the assumption is that cuesheets will be used to describe the track breakup of a ripped CD and it's extremely uncommon for CDs to have more than 99 tracks.

Even most books don't have over 100 chapters (and it's quite possible to split them into smaller files anyway, there's not generally the same reason for wanting a single-file solution) so larger cuesheets seems like an extremely special case.

[linuxstb]

Yes, cuesheets were invented for describing the indexing on CDs, and CDs can only have a maximum of 99 tracks.  That's why the cuesheet limit in Rockbox is 99 - it's not arbitrary.

I expect Rockbox would be happy if you increased that limit (although the parser may assume a two-digit track number), but don't expect other cuesheet software to support them.