SEGA CD simple audio tech question

[tomaitheous]

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.

Err.. ok. Fair enough. Then explain yourself. Because if you're not talking about this:

how does SEGA CD (real hardware) handle the 2 second pre/post gap?
ive read/know that "space" is needed for seeking, but is it used during playback?

Then I'm lost.

Last I checked, you were talking about pregaps; how emulators weren't handling them correctly compared to the real hardware, how the longer pause for the start of the track annoyed you on emulators, and recently how some official CDs are 3/100ths off for whatever you want them to be? And.. IIRC you're trying to fix all of this for the emulation side (I'm assuming because you can't get the emulation author's to fix it). Am I off track? What's the score here? What's next?

[ThugsRook]

sorry for the thread confusion. a lot of what i posted is blog, and not completely explained.


SEGA CD emulation sucked...

there are (were) 2 problems with SEGA CD (redbook) emulation, looping and track indexing. looping problem is an emulation bug, incorrect indexing is actually a problem from the original disc ~ not an emulation bug. both problems are now completely resolved. the audio tracks need to be edited, they wont work correctly as they are on the discs or bin+cues. track indexing needs to be repaired and end-of-track blank space needs to be cropped.

i spent a few weeks working with different programs and techniques to simplify the repairs. if all SEGA CDs have the same problem, then they should all have the same resolve, right?

fast forward: all work is completed and tested. takes me maybe 30 mins tops to repair a SEGA CD for emulation, and the repairs are guarenteed correct. same process and repairs for all SEGA CDs. it works absolutely perfectly!

the final product ends up in ISO/WAV or ISO/MP3 formats. (user preference)

the project is complete, but its not like im gonna open up a SEGA CD ROMsite
the best i can do is explain the problems, and the repair techniques... which is not exactly for noobies but isnt too complicated.


i can understand that if you dont SEGA CD on emu, then you dont know what the problems are.
however, most ppl that play SEGA CD on emu never played on real hardware and dont know the difference!

well anyways, its fixed, its done, its completed. SEGA CD emulation does not have to suck, it can be easily repaired.

[tomaitheous]

there are (were) 2 problems with SEGA CD (redbook) emulation, looping and track indexing. looping problem is an emulation bug, incorrect indexing is actually a problem from the original disc ~ not an emulation bug. both problems are now completely resolved. the audio tracks need to be edited, they wont work correctly as they are on the discs or bin+cues. track indexing needs to be repaired and end-of-track blank space needs to be cropped.

Ok, so let me verify the problem on the emulation side that you're having. When the track loops, it loops back to the pregap point (index 00) instead of the normal index 01 (like the real hardware would) - thus there's an additional gap of silence when looping the track. Is this correct? That's why I asked you if you mounted the CUE in the OS as a virtual drive (in which the emulator thinks it's running a real cd drive) VS just loading the CUE file in the emulator itself. And, if there was a difference (I'm suspecting there should be) because it's two different method of CD emulation (internal to the emulator, external to the emulator). And this is for Kega, right?

[ThugsRook]

Ok, so let me verify the problem on the emulation side that you're having. When the track loops, it loops back to the pregap point (index 00) instead of the normal index 01 (like the real hardware would) - thus there's an additional gap of silence when looping the track. Is this correct? That's why I asked you if you mounted the CUE in the OS as a virtual drive (in which the emulator thinks it's running a real cd drive) VS just loading the CUE file in the emulator itself. And, if there was a difference (I'm suspecting there should be) because it's two different method of CD emulation (internal to the emulator, external to the emulator). And this is for Kega, right?

actually KEGA ignores index 00, but yea its playing pre/postgaps leaving lots of dead air. if the index is off that dead air will also have a nasty noise at the end before looping.

ive played real SEGA CDs in KEGA (not burnt images), same exact disappointing behavior as bin+cue.

KEGA treats everything as a "track", not as a CD. so we need to give it "clean" tracks, not CD images, not CD rips.




* if KEGA did reccognize index 00 in cue sheets, all these problems could just as easily be resolved with mild cue sheet editing. then we could play the bin+cue files perfectly without the need to rip them down further to iso+wav/mp3.

[tomaitheous]

actually KEGA ignores index 00, but yea its playing pre/postgaps leaving lots of dead air. if the index is off that dead air will also have a nasty noise at the end before looping.

ive played real SEGA CDs in KEGA (not burnt images), same exact disappointing behavior as bin+cue.

KEGA treats everything as a "track", not as a CD. so we need to give it "clean" tracks, not CD images, not CD rips.




* if KEGA did reccognize index 00 in cue sheets, all these problems could just as easily be resolved with mild cue sheet editing. then we could play the bin+cue files perfectly without the need to rip them down further to iso+wav/mp3.

I just tested Fusion (3.64) on windows 7 64bit. It does not play the pregaps from the audio tracks. The time between index 00 and index 01 *is* the pregap. I tested this two ways. First, I put loud audio in the pregap. On track loop, it did not play. Instead, it looped backed to index 01 as predicted. Second, I extended the current track to end in the middle of a song. The gap from the end of the song to the loop point back to index 01 was a total of ~0.420 seconds. That looks like emulated 'seek' time. Pregap by spec cannot be less than 2 seconds. If it was playing the pregap, it would be starting at index 00. For CD player specs, track seeks/requests always start at index 01. If you play a track continuously through from track to track (without a track request), then the CD unit will play index 00 for the *following* tracks. That's all to spec.

Now, I do have a silence gap for my cue/bin (single file). My track has a total time of 1:49. But the silence in the rip is *hardcoded*. It has nothing to do with Kega or emulation. So my question is; what are you doing to your setup? Are you editing your audio tracks in audio editor or are you editing your CUE sheet (or both)?

[tomaitheous]

Oh crap. Sorry. There is a third test I need to run still. (track 1 index 1 -> track 2 index 0 -> loop back when index 1 of track 2) If it fails that, then yeah - it'll play the pregap of the next track before looping back.

[ThugsRook]

as stated... Index 00 is ignored.
KEGA works backwards ~ pregap becomes postgap on the previous track, hence the dead air when looping.

bin+cue and mp3 or wav have the pre/postgaps hardcoded. if you rip them you get the gaps too. (as postgaps)

both:
i edit the cue sheet to align the indexing correctly.
i then use the cue sheet to rip the ISO and WAV files. (ISObuster)
then i crop all blank space from the end of wav files. (wav editor)

game is played via ISO+WAV or ISO+MP3.

[tomaitheous]

Yup. That's what it's doing. Be it virtual mount drive or internal cue load to the emulator. There's technically is no postgap in the CD spec. Only pregap. Pregap is the space between index 00 and index 01 of a track. The space between any other indexes for that track have no name. The postgap command for CUE sheets just inserts silence, unlike the pregap command that setups index 00 for you (as well as put silence in that section). Anyway, it continues to play into the next track until it encounters index 01 of the next track, then it loops back to index 01 of the previous track. Afaik, this is completely wrong behavior. But what's weird, is that it's doing that for the virtual drive. So I assume it would do it with a real CD in the PC drive (emulation still). Now I fully understand. Some of your explanations/descriptions were slightly wrong, which made for the confusion, but now that I know what you're referring to - looking back through the thread your posts make sense.

I know you're making these discs for yourself because you use SegaCD emulation issue, but wouldn't it be worth bring this up to Steve Snake's attention so he can just fix it? This also has me curious about other CD emulators and CDDA. Thumbs up for figuring this out (even if it took a few pages in the thread).

[ThugsRook]

youve verified it! awesome! now you understand.

TYVM


yes, i need to point Steve to this thread, now that i know im not nuts



EDIT: ah! i finally realized why you guys where bitchin about the MP3 loop tracks...

SEGA CD "loop tracks" would be better described as "tracks that repeat". they dont actually loop in that sense, they just fade out and restart. nothing really smooth, seamless, or gapless about it. my gripe about it was the 2-5 seconds of dead air before restarting, not a nice clean seamless loop or anything like that.

[ThugsRook]

need to keep in mind, even if Steve fixes things... (index 00)

> about half the current bin+cue files will still need cue sheet repairs. (to insert index 00 info)
> current iso/mp3 rips are still incorrect.
> real CDs still dont work right.

fixing the data files yourself will still get you a better SEGA CD experience. (SEGA CD track indexing is extremely sloppy)