Are you using a build that is linked with SDL_Sound?

jmarsh wrote on 2020-10-19, 13:57:

Are you using a build that is linked with SDL_Sound?

Yup, running the latest SVN (compiled yesterday) on Linux
libSDL_sound-1.0.so.1 => /lib/x86_64-linux-gnu/libSDL_sound-1.0.so.1

is the file case correct for all the files ?

Qbix wrote on 2020-10-19, 14:13:

is the file case correct for all the files ?

Yup, all lowercase.

EDIT: Almost forgot, it works when I only have the ISO in the CUE file.

EDIT2: Might be the SDL_SOUND,
purgedthe SDL packages, reinstalled them, compiling latest SVN now
(this is probably my fault, it usually is 😁)

You need the SDL_Sound dev package for linking (and make sure it is for SDL 1.x, not 2.x) as well as the runtime library. Check the output of ./configure to make sure it gets found.

jmarsh wrote on 2020-10-19, 15:15:

You need the SDL_Sound dev package for linking (and make sure it is for SDL 1.x, not 2.x) as well as the runtime library. Check the output of ./configure to make sure it gets found.

Indeed, the libsdl1.2-dev was missing. I feel stupid 🙁

Well the CUE sheets are being loaded 😁

Pllaying the audiotracks only seem to work with OGG.
MP3 and FLAC stay silent ?

Does one EDIT a copy of the original CUE sheet ?
or build a new one from scratch ?

What is considered best practice ?

Akuma wrote on 2020-10-20, 19:33:

Does one EDIT a copy of the original CUE sheet ?
or build a new one from scratch ?

What is considered best practice ?

Obviously to use a tool to build it properly.

Because this:

1FILE "image.iso" BINARY
22	  TRACK 01 MODE1/2048
33	    INDEX 01 00:00:00
44	FILE "track02.ogg" MP3
55	  TRACK 02 AUDIO
66	    PREGAP 00:02:00
77	    INDEX 01 00:00:00

Is definitely incorrect. You are basically saying that both tracks start at the same time (00:00:00)

dr_st wrote on 2020-10-21, 07:20:

Obviously to use a tool to build it properly. […]
Show full quote

Akuma wrote on 2020-10-20, 19:33:

Does one EDIT a copy of the original CUE sheet ?
or build a new one from scratch ?

What is considered best practice ?

Obviously to use a tool to build it properly.

Because this:

Copy code to clipboard

1FILE "image.iso" BINARY
22	  TRACK 01 MODE1/2048
33	    INDEX 01 00:00:00
44	FILE "track02.ogg" MP3
55	  TRACK 02 AUDIO
66	    PREGAP 00:02:00
77	    INDEX 01 00:00:00

Is definitely incorrect. You are basically saying that both tracks start at the same time (00:00:00)

Appreciate your time, but I think you're missing something 😁

dr_st wrote on 2020-10-21, 07:20:

Obviously to use a tool to build it properly. […]
Show full quote

Obviously to use a tool to build it properly.

Because this:

Copy code to clipboard

1FILE "image.iso" BINARY
22	  TRACK 01 MODE1/2048
33	    INDEX 01 00:00:00
44	FILE "track02.ogg" MP3
55	  TRACK 02 AUDIO
66	    PREGAP 00:02:00
77	    INDEX 01 00:00:00

Is definitely incorrect. You are basically saying that both tracks start at the same time (00:00:00)

It is valid. INDEX parameters aren't absolute timecodes, they are offsets (usually referring to the current FILE) expressed as minutes:seconds:frames. "INDEX 01 00:00:00" means use the current file beginning from the start.

I'm having trouble understanding how to convert the following CUE:

1FILE "myfile.bin" BINARY
2  TRACK 01 MODE2/2352
3    INDEX 01 00:00:00
4  TRACK 02 AUDIO
5    PREGAP 00:02:00
6    INDEX 01 33:40:15
7  TRACK 03 AUDIO
8    INDEX 00 37:54:70
9    INDEX 01 37:55:03
10...

to:

1FILE "myfile01.iso" BINARY
2  TRACK 01 MODE1/2048
3    INDEX 01 00:00:00
4FILE "myfile02.ogg" OGG
5  TRACK 02 AUDIO
6    PREGAP 00:02:00
7    INDEX 01 00:00:00
8FILE "myfile03.ogg" OGG
9  TRACK 03 AUDIO
10    INDEX 00 37:54:70 <-- How do I process these ?  
11    INDEX 01 37:55:03 <-- 00:00:00 and 00:00:$(75-70+3) ?

Ha! I found something here: http://www.totalsonic.net/cuesheetsyntax.htm

1INDEX 0 Specifies the starting time of the track “pregap”

Based on that information, I think this should be it: (but wtf do I know 🤣)

1FILE "myfile03.ogg" OGG
2  TRACK 03 AUDIO
3    PREGAP 00:02:00
4    INDEX 01 00:00:00

Does anyone know more ?

Depends if the ripping software started dumping the track from index 0 or index 1.
If it started ripping at index 0 the pregap is included in the .ogg file, so you'd want this:
INDEX 00 00:00:00
INDEX 01 00:00:08 ; 75 frames in one second so 37:55:03 - 37:54:70 = 00:00:08 (length of pregap/index 0 -> index 1)

If it started ripping at index 1 you need to use PREGAP instead (which means "insert silence"):
PREGAP 00:00:08
INDEX 01 00:00:00

Some rippers append the pregap to the end of the previous track, which would require something like this:
FILE "myfile02.ogg" MP3
TRACK 02 AUDIO
PREGAP 00:02:00
INDEX 01 00:00:00
TRACK 03 AUDIO
INDEX 00 04:14:55 ; 37:54:70 - 33:40:15 (length of track 2 audio)
FILE "myfile03.ogg" MP3
INDEX 01 00:00:00

(Note that all compressed audio should use "MP3" filetype regardless of their actual format."

Yikes!, that makes scripting it a lot tougher.

Regarding the MP3 filetype, I'd take it to be best practice but not mandatory ( it seems to work with OGG/FLAC)

It's one of several reasons why using individual files for each track is a bad idea, better off just sticking with a mixed-mode .iso.

jmarsh wrote on 2020-10-21, 07:39:

It is valid. INDEX parameters aren't absolute timecodes, they are offsets (usually referring to the current FILE) expressed as minutes:seconds:frames. "INDEX 01 00:00:00" means use the current file beginning from the start.

I see. You are correct, of course. The index refers to each file separately and not to the overall position on the emulated disk. I looked at the wrong example on the wiki, the one which used a single binary CD image. 😊

jmarsh wrote on 2020-10-21, 09:16:

It's one of several reasons why using individual files for each track is a bad idea, better off just sticking with a mixed-mode .iso.

How would that work with OGG/FLAC/MP3 ?

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