SEGA CD simple audio tech question

[Chilly Willy]

Well, SEGA states that CDs MUST have a two second index 0 between tracks or the disc won't be accepted. That's common on most CDs with CDDA tracks for the music - both Quake and Quake 2 have two second gaps as well.

[ThugsRook]

Well, SEGA states that CDs MUST have a two second index 0 between tracks or the disc won't be accepted.

oh yes, and i can confirm that real SEGA CDs (and bin+cues, and iso+mp3s) do indeed have 2 seconds of blank space between tracks. (even tho they do not have any INDEX 00 indicators)

the thing is...
SEGA CD hardware somehow has the ability to NOT play that 2 seconds of blank space during a loop.
emulators do not have that ability, and will mistakenly play the 2 seconds of blank space insted of looping. (in all formats and real cds)

my resolve to this? i remove all the 2 seconds of blank space from (the end of) all the audio tracks.
its crude, but it works perfectly in emulation.

so yea, either KEGA needs to be fixed, or the files need to be fixed for use in KEGA.

im hoping your current mode1 project will uncover some info.

[Sik]

Pause between tracks

A two second pause (muting) is required before and after the CD-ROM track, before CD-DA tracks and after the last CD-DA track in accordance with the "YELLOW BOOK." This is to suppress (during seeking) final sounds of the previous tune when it is played with an audio player.

Note it explicitly says this is required for proper operation in an audio player specifically, it says nothing about the BIOS requiring it.

I guess we can't know if it really does unless we modify a game to remove the pauses and try it on real hardware. After all, the docs also say the disc must conform to ISO9660, but in reality handling the filesystem is up to the game code and the BIOS only cares about the data in the initial sectors.

[ThugsRook]

Note it explicitly says this is required for proper operation in an audio player specifically, it says nothing about the BIOS requiring it.

I guess we can't know if it really does unless we modify a game to remove the pauses and try it on real hardware. After all, the docs also say the disc must conform to ISO9660, but in reality handling the filesystem is up to the game code and the BIOS only cares about the data in the initial sectors.

i can confirm that removing the "2 second pregap/postgap" stuff from a physical SEGA CD makes it very very difficult for the drive to find tracks quickly, if at all.

of course in BIN format it doesnt matter, cause its not a physical disc. it just looks up the track index in the cue sheet and plays it, instantly.

[Chilly Willy]

I think it depends on your ripper as to how the tracks get ripped and the gaps handled. I use rubbyripper, widely regarded as the most accurate FREE ripper out (constantly compared to the best commercial ripper), and here's the start of the cue for the audio on Sonic CD according to it:

PERFORMER "Sonic CD"
TITLE "Sonic CD US final 1006"
FILE "02 - unnamed.ogg" WAVE
  TRACK 02 AUDIO
    TITLE "<unnamed>"
    PERFORMER "Sonic CD"
    INDEX 01 00:00:00
FILE "03 - Palmtree Panic.ogg" WAVE
  TRACK 03 AUDIO
    TITLE "Palmtree Panic"
    PERFORMER "Sonic CD"
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "04 - Palmtree Panic G Mix.ogg" WAVE
  TRACK 04 AUDIO
    TITLE "Palmtree Panic \"G\" Mix"
    PERFORMER "Sonic CD"
    INDEX 00 00:00:00
    INDEX 01 00:02:02
FILE "05 - Palmtree Panic B Mix.ogg" WAVE
  TRACK 05 AUDIO
    TITLE "Palmtree Panic \"B\" Mix"
    PERFORMER "Sonic CD"
    INDEX 00 00:00:00
    INDEX 01 00:02:00

Note that I asked RR not to rip the data track since it's not audio. That's why the cue starts at track 2 at time 0. Note the two second INDEX 0 on each track following... that's the way all my mixed CDs look.

[ThugsRook]

^ that is an ISO+WAV type of cue sheet ~ useless for emulators. (ISO+WAV does not use or need cue sheets)
and to be honest ~ thats not the best way to rebuild a SEGA CD. (we can save that for another thread )


anyways,
example: BIN+CUE cue sheet for emulation...

FILE "SONIC CD.BIN" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 01 13:10:11
  TRACK 03 AUDIO
    INDEX 01 13:16:25
  TRACK 04 AUDIO
    INDEX 01 15:07:39
  TRACK 05 AUDIO
    INDEX 01 16:29:42

really the whole problem with SEGA CD emulation is the CD "format" itself.
(physically) remove all that silly pregap/postgap/blank space stuff and it works perfectly (in a data format of course)

[ThugsRook]

as it turns out, these (real) SEGA CDs arent all that innocent themselves - they have track indexing errors!

whats happened is that roughly 3/100ths of a second is cropped off the beginning of some tracks, placing that 3/100ths of a second in the pregap/postgap zone of the previous track. on real hardware this would be hardly noticable at all (since real hardware ignores pregap/postgap locations), but on emulators it creates lots of dead air and an audible mess. (at the end of tracks)

two seriously offending examples would be Ecco the Dolphin and Android Assault.

these errors are easily correctable via cue sheet for both real hardware and emulators.

[ThugsRook]

^ can add Final Fight CD to the list of fucked up SEGA CD indexing.


ok, so its now become apparently obvious that KEGA Fusion is not at fault here with its inability to properly emulate SEGA CD. there is just no fuckin way its gonna be able to compensate for all the crap audio errors going on with SEGA CD in data format. (disk format maybe, data = no way) the data needs to be modified (as im doing), period.





here's a very quick rundown on how to repair these CDs for data format emulation:

1) rip CD to bin+cue
2) edit cue sheet for ripping purposes
3) rip track 01.iso and wav files (from the bin+cue)
4) check wav files & repair indexing via cue sheet as needed ~ and re-rip
5) crop all blank space from the end of all wav tracks
6) convert to 320 CBR STEREO MP3s (optional)
7) rename files

DONE!

[tomaitheous]

You're going on about 3/100ths of a second and yet you list MP3 as an option for audio storage. Lol

[ThugsRook]

You're going on about 3/100ths of a second and yet you list MP3 as an option for audio storage. Lol

the audio quality of these tracks is so poor MP3'ing them really doesnt matter.
actually, MP3 helps get rid of some of the hiss.

if you want WAV files, thats fine. hell i could even re-bin+cue them if i wanted, but theres no real point to that.

[Jax184]

A properly encoded Mp3 will sound just like the source material in almost all cases. We're just so used to hearing junk off of P2P networks that we think Mp3s are fundamentally awful. Stuff that was once a low bitrate Realaudio file before some puddinghead used an ancient media program on a Pentium 2 to re-encode as Mp3, things like that. When done with care, Mp3s sound great. I did a lot of testing and concluded that my ears can't tell the difference with my Sennheiser headphones.

But it does seem funny to use a format which is wildly known for having trouble with gapless playback, etc, in a situation where you want more control over how it loops.

[Chilly Willy]

He's talking about the latency of mp3, not the quality. Even the highest quality mp3 has a latency high enough (>100 ms) that complaining about 30 ms is silly. In fact, maybe half the "problems" with the CD audio the original guy was complaining about are due to mp3 latency, not the original CDDA.

You can find a chart comparing different audio codecs (including the latency) here:
http://en.wikipedia.org/wiki/Compari...hnical_details

[ThugsRook]

this thread isnt about MP3 latency.

latency doesnt make part of the next track play, or cause 5 secs of dead air while a track loops, or currupt the file to begin with.
the problem isnt latency, the problem is indexing and blank space.

never mind tho ~ i dont think anyone here is understanding what im fixing anyways, cause you guys dont SEGA CD on emu.

[tomaitheous]

this thread isnt about MP3 latency.

latency doesnt make part of the next track play, or cause 5 secs of dead air while a track loops, or currupt the file to begin with.
the problem isnt latency, the problem is indexing and blank space.

never mind tho ~ i dont think anyone here is understanding what im fixing anyways, cause you guys dont SEGA CD on emu.

I do understand what you're talking about in this thread, but I just find the fact that you're anal about 3/100ths of a second difference as a measure of quality and yet list MP3 as a viable option for storage( MP3's tend to have a shorter encoded length compared to the source). I just find it funny. "Nevermind the $500 macco paint job, it's about the $1000 bucket seats I got..."

Anyway. I did want to point out something though; cue/bin doesn't guarantee anything. If a cue is setup wrong, a cue is setup wrong. An CUE/ISO/WAVE setup can produce *everything* needed that a CUE/BIN setup can. About the only problem I've seen with CUE/ISO/WAVE setup is that *some* version of Nero (not sure which) was burning the data track (cooked mode) as mode 2 form 1 when the CUE specifically told it to use mode 1. My version of Nero never had that problem though.



Also (and mostly importantly), did you see any difference results with mounting the CUE with 3rd party software as opposed to just opening the CUE with the emulator?

[ThugsRook]

I do understand what you're talking about in this thread, but I just find the fact that you're anal about 3/100ths of a second difference as a measure of quality and yet list MP3 as a viable option for storage( MP3's tend to have a shorter encoded length compared to the source). I just find it funny. "Nevermind the $500 macco paint job, it's about the $1000 bucket seats I got..."

Anyway. I did want to point out something though; cue/bin doesn't guarantee anything. If a cue is setup wrong, a cue is setup wrong. An CUE/ISO/WAVE setup can produce *everything* needed that a CUE/BIN setup can. About the only problem I've seen with CUE/ISO/WAVE setup is that *some* version of Nero (not sure which) was burning the data track (cooked mode) as mode 2 form 1 when the CUE specifically told it to use mode 1. My version of Nero never had that problem though.



Also (and mostly importantly), did you see any difference results with mounting the CUE with 3rd party software as opposed to just opening the CUE with the emulator?

no, sorry, you dont understand what im fixing. nothing you just posted has any relivence at all. i dont know where to begin to correct you

other then, the MP3s turn out to be 2 seconds longer for every 35 minutes of track.
MP3 format is NOT an issue for errors, nor is bin+cue, the original CD is.