CUE-Sheet support

[maxmitti]

I tried to open a .cue-file which is belonging to a single .ape-file.
Bomi plays the file and shows the single songs as Chapters in the Play submenu.

Maybe it would be possible to show each song of a CUE-Sheet separately in the playlist. So in this way shuffle would work on per song basis instead of per CUE-Sheet (a CUE-Sheet usually represents an album) basis. And navigation would also be quicker than navigating through the menu.

Maybe it would be also an idea to show real chapters in the playlist, but I am not sure about that.

[bylee20]

I think it would be just fine to handle cue sheet as a playlist.

[maxmitti]

If there is an option to append one playlist to another, it would be fine, yes.

[bylee20]

Done. Thank you.

Maybe it would be also an idea to show real chapters in the playlist, but I am not sure about that.

This is not a good idea for non-tree playlist because it will just make entries in playlist bloated, especially for chaptered video searies.

[maxmitti]

Thans for the fast fix, although it seems the bar which displays buffering is wrong when playing tracks out of a CUE-sheet.

[bylee20]

What is wrong?

[maxmitti]

Maybe it's supposed to be like this but the buffer bar is always at a fixed distance ahead of the playing position.
Also the distance between the buffer bar and the playing is position is bigger, when the track begins later in the music file.

[bylee20]

at a fixed distance ahead of the playing position.

Demuxer is full with cache.

Also the distance between the buffer bar and the playing is position is bigger,

Duration is different for each track, so relative length would be diffferent, too.

If you want to ajdust cache length in demuxer, check cache tab in preferences.

[maxmitti]

I thought the cache bar length is calculated based on the complete audio file instead of the track, this would describe the behaviour.

With normal files the cache is much smaller, thats why i thought it may be wrong.

[bylee20]

Cue sheet was recongized as remote URL, so wrong cache option was being applied. Now fixed. Thanks.

[maxmitti]

Great, i must thank you.

[maxmitti]

Well, when you look at my screenshot with the seekbar again, you can see another bug.
The time position display shows the position of the whole .flac-File instead of the track only, i think you forgot to subtract the track offset, also the complete song duration display (the one you get when you click on the remaining time) has the same issue.

[bylee20]

It's not a bug. Why do I have to subtract index?
There's no such rule to enforce start time as zero.
Start time is specified by the file and if it's not specified, it will be zero.
In this case, the start time is specified in cue sheet so it should be respected.

[maxmitti]

I think you misunderstood me.
In the screenshot the current position is shown as 33:38. This is the position in the complete .flac-file, but not in the track itself. The track is only 2 minutes long and the track position is at about 30 seconds.

[bylee20]

No I didn't.
Check your cue sheet. You'll see INDEX01 for the track is specified and the value matches.
This is the start time of the (virtual) track for cue sheet.
This is my interpretation because cue sheet spec does not tell the start time should be zero.

[maxmitti]

Yes you are right, but I would expect the shown start time to be zero.
Other players do this as well and in my opinion it makes more sense.

[bylee20]

Other players do this as well and in my opinion it makes more sense.

Why do you think zero value makes more sense?
It's a way to abandon available information which is usually not a good way.

[maxmitti]

Because the current track is not playing for the time shown, but for the time since the start of the track.

[bylee20]

Because the current track is not playing for the time shown, but for the time since the start of the track.

It is the time in the file.

[maxmitti]

When i read 33:38 i expect the current track to be already playing for that time, but its only playing since 30 seconds. Thats confusing, also if you look at the relation of the seekbar.

[bylee20]

When i read 33:38 i expect the current track to be already playing for that time

Well, you just should not expect so, because it's not.
This is not only about cue sheet.
Generally, you're not suppose to expect so because there's no such rule to restrict start time to zero.
For instance, lots of ts files reports actual start time in TV program.

It makes much more sense display the real timestamp in file unless it's useless.
There's no reason to shift all timestamp.

Thats confusing, also if you look at the relation of the seekbar.

What kind of relation?
Seekbar is always scaled based on duration not absolute start/end time, so there's no problem.

[maxmitti]

Yes, generally its a bad idea, but cue sheets are normally used for music albums, and there it would make sense.

[bylee20]

Done, but please carefully test it.
It may be quite buggy because this change introduces a break of timestamp between demuxer and player, which may cause unexpected problems.
There are too many corner cases because timestamp is very important imformation for a player and I'm not sure if I've handled all cases or not.

[maxmitti]

Thank you very much, seems to be working.

[maxmitti]

It looks like restoring of the last playback position is broken.
Because when the playback position is restored, i think the position of the track is set for the whole file instead of the track.
For example the track which begins at 33:10 in the .flac-file has a track position of -33:05 when restoring the previous track position of 0:05.

[bylee20]

Fixed.