VOGONS

Common searches


CUE sheet troubles :/

Topic actions

Reply 21 of 29, by realnc

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2020-10-21, 11:12:

It wouldn't. Compressed audio brings other problems like slow seeking, loss of quality, incorrect tracks lengths...

Not with FLAC. It's lossless and bit-perfect. Seeking might be a bit slower than uncompressed WAV, but still orders of magnitude faster than a CD-ROM drive.

This is why the CHD format of MAME for example uses FLAC to compress audio tracks.

Reply 22 of 29, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
realnc wrote on 2020-10-21, 21:15:

Not with FLAC. It's lossless and bit-perfect. Seeking might be a bit slower than uncompressed WAV, but still orders of magnitude faster than a CD-ROM drive.

You might assume so since it's lossless, but like all codecs it still has a minimum framesize so if the total number of samples is not an exact multiple of that amount, padding gets added. The actual number of samples contained in the final block is stored in the FLAC headers but unfortunately not handled by the core decoder (libflac) and left up to the calling application to deal with, which unfortunately SDL_Sound neglects to do...
So tracks gets padded with extra samples, and due to the nature of cue sheets this causes each successive track to get increasingly shifted away from their original start time.

Reply 23 of 29, by Akuma

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2020-10-21, 23:56:

You might assume so since it's lossless, but like all codecs it still has a minimum framesize so if the total number of samples is not an exact multiple of that amount, padding gets added. The actual number of samples contained in the final block is stored in the FLAC headers but unfortunately not handled by the core decoder (libflac) and left up to the calling application to deal with, which unfortunately SDL_Sound neglects to do...
So tracks gets padded with extra samples, and due to the nature of cue sheets this causes each successive track to get increasingly shifted away from their original start time.

Is this also present in SDL2 ? or does this needs to be fixed in libflac ?

Reply 24 of 29, by Akuma

User metadata
Rank Member
Rank
Member

Well I think I sorted all my problems with the CUE sheet, so I automated it:
BIN/CUE to ISO/CUE converter v1.09, supports : FLAC,MP3,OGG,OPUS (script)

That index recalculation wasn't that hard in retrospect 😁

Reply 25 of 29, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2020-10-21, 23:56:

You might assume so since it's lossless, but like all codecs it still has a minimum framesize so if the total number of samples is not an exact multiple of that amount, padding gets added. The actual number of samples contained in the final block is stored in the FLAC headers but unfortunately not handled by the core decoder (libflac) and left up to the calling application to deal with, which unfortunately SDL_Sound neglects to do...
So tracks gets padded with extra samples, and due to the nature of cue sheets this causes each successive track to get increasingly shifted away from their original start time.

Which libFLAC-based DOSBoxes are you referring to that read compressed FLAC tracks that are eventually affected by this CUE-sheet time drift?

The only DOSBoxes that are capable of reading FLAC tracks all use my CDDA patch (AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks), which uses dr_flac, not libFLAC.

Regarding length calculation: dr_flac returns the exact number of PCM samples per the FLAC STREAMINFO header, and should provide a sample-exact length value no different than from BIN/CUE or WAV files (to-be-confirmed).

Regarding seek-performance, adding seek-points after encoding your FLAC files is advised to ensure very low-latency seeks:

metaflac --add-seekpoint=1s "flacfile"

Regarding MP3 seeking, the CDDA patch implements a FLAC-like seek-table strategy (which isn't part of the MP3 standard), to also provide extremely low latency PCM-exact seeking.
I wrote a bit about it here in the comment block at the top here: https://github.com/dosbox-staging/dosbox-stag … _seek_table.cpp

I've previously benchmarked the seek performance for each codec used in my CDDA patch; pasted here for convenience:

stb_vorbis
CDROM: seek(34485024) took 5.321646 ms
CDROM: seek(183027936) took 5.928965 ms
CDROM: seek(337883616) took 6.493050 ms
CDROM: seek(1759296) took 4.413499 ms

dr_mp3 (using CDDA mp3-seek-table enhancement)
CDROM: seek(35574000) took 0.818466 ms
CDROM: seek(189785232) took 0.778496 ms
CDROM: seek(334329744) took 0.396842 ms
CDROM: seek(6115200) took 0.266457 ms

sdl_sound's WAV decoder
CDROM: seek(32165952) took 0.015657 ms
CDROM: seek(186301920) took 2.208570 ms
CDROM: seek(339344208) took 2.146041 ms
CDROM: seek(200296320) took 2.193242 ms
CDROM: seek(5268480) took 0.014133 ms

dr_flac pre-generated seekpoints, one every 1s of audio
CDROM: seek(29124816) took 2.617673 ms
CDROM: seek(189147840) took 2.730340 ms
CDROM: seek(336470064) took 2.725294 ms
CDROM: seek(1759296) took 0.343579 ms

xiph opus
CDROM: seek(35574000) took 0.332695 ms
CDROM: seek(189147840) took 0.356307 ms
CDROM: seek(333777024) took 0.365779 ms
CDROM: seek(5268480) took 0.238305 ms

No doubt these seek times are slower than BIN/CUE and I agree with you in that strict relative sense.

But let's let's look at it from the users perspective (as that's where this question originated) and not confuse people by saying "slow", when we both know that's certainly not the case:

  • A physical CDROMs requires tenths-of-a-second to seek, so all of these times are between two to three orders of magnitude faster.
  • The slowest seeking time here, STB-Vorbis at ~6.4 ms, can still perform two seeks even before the next video frame is shown, assuming a 70 Hz frame-rate.

Reply 26 of 29, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote on 2020-10-22, 10:12:

The only DOSBoxes that are capable of reading FLAC tracks all use my CDDA patch (AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks), which uses dr_flac, not libFLAC.

You know that's not true, because you participated in the original FLAC patch thread: FLAC support

But let's let's look at it from the users perspective (as that's where this question originated) and not confuse people by sayin […]
Show full quote

But let's let's look at it from the users perspective (as that's where this question originated) and not confuse people by saying "slow", when we both know that's certainly not the case:

  • A physical CDROMs requires tenths-of-a-second to seek, so all of these times are between two to three orders of magnitude faster.
  • The slowest seeking time here, STB-Vorbis at ~6.4 ms, can still perform two seeks even before the next video frame is shown, assuming a 70 Hz frame-rate.

You are missing an important difference between seek times on a real device vs. DOSBox's emulation. When a real device is seeking the rest of the system carries on running. Interrupts still occur and can be serviced, timers keep ticking, etc. With DOSBox as soon as the cpu emulation executes the INT instruction to call mscdex everything is frozen.
Halting the entire system for multiple milliseconds can majorly throw out the timing, especially if cycles is set to auto and/or the system forces vsync to be enabled. In some cases it can cause crashes as multiple interrupts all get queued at the same time (when processing resumes), triggering stack overflows.
If a game regularly plays sound samples that are all contained within a single track it is not going to be a very good experience.

Reply 27 of 29, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2020-10-22, 11:00:
krcroft wrote on 2020-10-22, 10:12:

The only DOSBoxes that are capable of reading FLAC tracks all use my CDDA patch (AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks), which uses dr_flac, not libFLAC.

You know that's not true, because you participated in the original FLAC patch thread: FLAC support

I came across that the thread a year after the patch was authored, , failed to work and gave up, which is what drove me to start working on the CDDA patch.

So please tell me again.. where are these working instances of lib-FLAC based DOSBoxes that you're warning users about this CUE dilation issue?

jmarsh wrote on 2020-10-22, 11:00:
You are missing an important difference between seek times on a real device vs. DOSBox's emulation. When a real device is seekin […]
Show full quote
krcroft wrote on 2020-10-22, 10:12:
But let's let's look at it from the users perspective (as that's where this question originated) and not confuse people by sayin […]
Show full quote

But let's let's look at it from the users perspective (as that's where this question originated) and not confuse people by saying "slow", when we both know that's certainly not the case:

  • A physical CDROMs requires tenths-of-a-second to seek, so all of these times are between two to three orders of magnitude faster.
  • The slowest seeking time here, STB-Vorbis at ~6.4 ms, can still perform two seeks even before the next video frame is shown, assuming a 70 Hz frame-rate.

You are missing an important difference between seek times on a real device vs. DOSBox's emulation. When a real device is seeking the rest of the system carries on running. Interrupts still occur and can be serviced, timers keep ticking, etc. With DOSBox as soon as the cpu emulation executes the INT instruction to call mscdex everything is frozen.
Halting the entire system for multiple milliseconds can majorly throw out the timing, especially if cycles is set to auto and/or the system forces vsync to be enabled. In some cases it can cause crashes as multiple interrupts all get queued at the same time (when processing resumes), triggering stack overflows.
If a game regularly plays sound samples that are all contained within a single track it is not going to be a very good experience.

Rotating hard disks have a physical seek latency on the order of 10ms, therefore seeking and track changes within a 700 MiB BIN cold-cache file are going to incur the same multi-millisecond seek latency.

File IO in general in DOSBox isn't asynchronous and thus blocks the 1ms emulation loop. Spinning rust is the long pole here.. not the DOSBox BIN/CUE code or the codecs.

If we can't tolerate a millisecond disk seek without blowing up, then we've got a design issue.
(not arguing - I'd love to see more of the external 1ms-loop-blockers made asynchronous!)

That said, I've spent countless hours over the years running pure FLAC / Opus tests on even slower hardware.. and have yet to see DOSBox crash or even hiccup for that matter. Do you have some crash examples?

Reply 28 of 29, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote on 2020-10-22, 10:12:

The only DOSBoxes that are capable of reading FLAC tracks all use my CDDA patch (AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks), which uses dr_flac, not libFLAC

Btw, is it possible to "extract" your latest version of the patch from GIT somehow? If so I could try to update it in ECE again.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)