Is CD+G possible?

[rhester72]

MAME's TG16-CD doesn't work either, but not terribly surprised...neither driver is very mature.

Going to experiment with Retroarch cores as time permits, since most support CHD now, but odds aren't great...lack of general CD+G support in console emulation was the reason I started this thread in the first place =)

If you're just looking to confirm the CD+G data is properly encoded in the CHD, and you have a USB burner, you can always reverse the process by unpacking the CHD back into TOC/BIN, then using cdrdao to burn that to a disc and play it back in a CD+G player.

[dshadoff]

@dshadoff - well, not TGFX16 (yet), I tried and it locked up entirely. LOL

I tried - and while it doesn't lock up entirely, it seems to reject the disc/function.
When I go to the disc menu, then choose "graphics", it flips to the CD+G menu, and appears to perform a re-read, pauses briefly, then moves the pointer to the eject/reload disc icon. It hasn't locked up, but seems to think there is no disc at all. It shouldn't do this in any case, and I will look a little deeper into this if I can.

But specifically, I wasn't originally asking about just MAME/MiSTer players - I was more interested in seeing if there were other players which could use the cdrdao format to play back the digital rip (without having to burn a new disc). Some kind of player - not associated with gaming - is likely to exist...

[zakk4223]

Yeah, there's players. You just have to look for karaoke software, since it is used there.

Just for validation I was converting the toc/bin to mp3+cdg and then using a karaoke player to play them. I'm on linux though so the tools are a bit rough; there may be better options on windows.

I also keep seeing mentions that kega fusion can do cd+g, but I think that may require bin/sub rips

[dshadoff]

If you're just looking to confirm the CD+G data is properly encoded in the CHD, and you have a USB burner, you can always reverse the process by unpacking the CHD back into TOC/BIN, then using cdrdao to burn that to a disc and play it back in a CD+G player.

So I tried this, and found that there is no subchannel-related option for "cdrdao write".
Then I tried to take a step back, and us "cdrdao copy", because it does have a "--read-subchan" option... and it created an audio CD copy of the original... without any CD+G.

So, I still need some convincing.
Specific software recommendations please, because at the moment I think the suggestions being made haven't actually been validated.

And @zakk4223 , if you were able to make the MegaCD core work with CD+G (as one of your posts from several days ago implied), it would be nice to commit your changes - or if they're not ready yet, to post some code... I'm seeing that more pieces of code are needed than the posts here implied. At the very least, I'd like to see how my rips look.

[rhester72]

If you're just looking to confirm the CD+G data is properly encoded in the CHD, and you have a USB burner, you can always reverse the process by unpacking the CHD back into TOC/BIN, then using cdrdao to burn that to a disc and play it back in a CD+G player.

So I tried this, and found that there is no subchannel-related option for "cdrdao write".
Then I tried to take a step back, and us "cdrdao copy", because it does have a "--read-subchan" option... and it created an audio CD copy of the original... without any CD+G.

I'm genuinely not sure what you're saying here at all. write doesn't have a subchannel related option because it's going to write whatever's in the bin. All the read-subchan does is change the DAO read from a 2048-byte cooked sector to a 2352-byte raw sector that will capture the full data range. It might be worth reading up a bit on what subchannels are and how they are encoded if you want a better understanding of this, but the short version is that if there's subchannel data (of any kind) in a cdrdao rip, it will be present when written back.

I can't say why copy didn't work for you, unless you have a writer that's capable of reading subchannels but not writing them. That was common in the very early days of SCSI CD-RW, but it's been quite a long time since I've encountered such a drive. Still, perhaps they exist. *shrugs*

So, I still need some convincing.

Of what?

Specific software recommendations please, because at the moment I think the suggestions being made haven't actually been validated.

With respect, you entered this thread very confidently spreading a considerable amount of gross misinformation, from both hardware and software standpoints.

That being said, staying on the Raspbian train, showing the end-to-end process to get from the 'untrusted' CHD to observable results (via http://www.kibosh.org/cdgtools/)...

Code: Select all

rhester@cronus:~/cdgtools-0.3.2$ chdman extractcd -i Information\ Society\ -\ Information\ Society\ \[CD+G\].chd  -o is.toc
chdman - MAME Compressed Hunks of Data (CHD) manager 0.206 (unknown)
Output TOC:   is.toc
Output Data:  is.bin
Input CHD:    Information Society - Information Society [CD+G].chd
Extraction complete
rhester@cronus:~/cdgtools-0.3.2$ ./cdgrip.py -v is.toc
-----------------------------------------------------------
 cdgrip 0.3.2 / Kelvin Lawson 2005
-----------------------------------------------------------
-> Binfile: is.bin
-----------------------------------------------------------
-> Starting: track01
-> Track start byte = 0, Track Size = 50832720
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track01
-----------------------------------------------------------
-> Starting: track02
-> Track start byte = 50832720, Track Size = 46296576
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track02
-----------------------------------------------------------
-> Starting: track03
-> Track start byte = 97129296, Track Size = 40656384
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track03
-----------------------------------------------------------
-> Starting: track04
-> Track start byte = 137785680, Track Size = 50421456
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track04
-----------------------------------------------------------
-> Starting: track05
-> Track start byte = 188207136, Track Size = 55900080
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track05
-----------------------------------------------------------
-> Starting: track06
-> Track start byte = 244107216, Track Size = 42546240
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track06
-----------------------------------------------------------
-> Starting: track07
-> Track start byte = 286653456, Track Size = 46463040
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track07
-----------------------------------------------------------
-> Starting: track08
-> Track start byte = 333116496, Track Size = 54095904
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track08
-----------------------------------------------------------
-> Starting: track09
-> Track start byte = 387212400, Track Size = 85704480
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track09
-----------------------------------------------------------
-> Starting: track10
-> Track start byte = 472916880, Track Size = 12582720
-> Ripping audio
-> Encoding audio to mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
-> Ripping CD+G subchannel data
-> Deinterleaving raw CD+G data
-> Finished: track10
-----------------------------------------------------------
-> Not deleting the cdrdao output files (is.toc, is.bin)
-> Use --delete-bin-toc to delete them after ripping
-----------------------------------------------------------
-> CD+G rip complete
-----------------------------------------------------------

And @zakk4223 , if you were able to make the MegaCD core work with CD+G (as one of your posts from several days ago implied), it would be nice to commit your changes - or if they're not ready yet, to post some code... I'm seeing that more pieces of code are needed than the posts here implied. At the very least, I'd like to see how my rips look.

I've personally avoided bothering them because I'm taking it as read that when they have something they are ready to show, they'll make it known. That being said, the process above will let you see how your rips look with a wide variety of open source software on multiple platforms (VLC being among a great many others). If you're impatient, feel free to look at the direct output actually produced by the above process:

https://www.rendezvo.us/cdg_try2/mp3+cdg_test/

Please slow your roll a bit in the future, the aggression isn't a good look in a public forum.

EDIT: Added URL for cdgtools

[dshadoff]

So, I re-read my post and I don't see the aggression that you perceive... simply an appeal for more details, because the ones provided to-date have been inadequate. If it were so easy to accomplish, then certainly it should be easy to explain in detail.

You'll be pleased to know that I have now been successful in getting a CD+G rip using CloneCD, which I was also able to use - digitally - on a device: the TerraOnion MegaSD.

...So I have finally verified what I have been seeking to verify since the beginning of this thread: that I have found a digital format which demonstrably supports CD+G, and that I can obtain demonstrably good rips. It is a different format than what you have been showing; actually this format should be a lot more straightforward as it is not interleaved, but stored in a separate *.sub file.

Now that I actually have concrete infromation, I can start to look into *HOW* to get the remaining bits implemented (at least for TGFX16).

For those seeking to replicate, the concrete steps to creating the files is:
1) Download/Install CloneCD on Windows. Cute cartoon sheep logo. It'll ask to reboot; not needed. This probably would start the timer on the 21-day trial license (which will be probably 19 days more than I need).
2) Press the tile for "Read to Image File"
3) Within the sub-selection menu, select "Multimedia Audio CD"
4) Output files to their own folder -> there will be 4 files: same base filename, 4 extensions: *.ccd, *.cue, *.img, and *.sub . The *.sub file contains the subcodes, and they look exactly like the ones I have also seen from software called "CD Manipulator"

To play on MegaSD:
a) ensure that you have the latest BIOS for support - 1.04 R09 definitely supports it; 1.02 R04 definitely doesn't (I had to upgrade).
b) Place all 4 files in the same subfolder, as you would for any game or CD
c) From there, play it as you would a CD, but select the "CD+G" button on the CD Player control panel.
This format is also supported by their MODE product, and the upcoming SHDS3 PC Engine device (but not the SSDS3 PC Engine device)

[zakk4223]

You'll need a modified MiSTer binary and a modified core.

Main Mister: You can grab a pre-compiled version with the changes from the releases directory here: https://github.com/zakk4223/Main_Mister_ZQol
Use the latest file in the directory. If you'd prefer to not have all my weird input/autofire changes, look in the 'patches' directory for the Main_MiSter patch

I think this should also support bin/cue/sub, but I haven't tested it yet.

MegaCD: https://github.com/zakk4223/MegaCD_MiST ... 210703.rbf

[rhester72]

@dshadoff I think you are rather confused, as I literally started the thread saying I originally used CloneCD for this. However, what I didn't (but probably should have) say was that I deliberately was *NOT* looking to use that for MiSTer, being a (rather expensive) commercial product and a proprietary format, neither of which is good times for F/OSS projects. As CHD is already supported (not only by MiSTer, but a good number of other works that would also benefit from subcode handling, including finally implementing proper PSX protection), it's a very natural fit.

It was rather easy to get the impression from your tone that you simply didn't believe that CD+G data was being encoded into the CHDs, which was rather stunning given that you had someone who's been doing this for more than ten years plainly telling you so *and* a developer telling you they'd produced results from it (who even correctly noticed Hot Hits didn't have any!). I found that frankly astounding. If all you wanted was to know how to generate subcode data totally independent of what we were trying to accomplish, you could have just asked - or Googled, for that matter (which you finally presumably did).

I'm glad you ultimately got the results you wanted.

[dshadoff]

You'll need a modified MiSTer binary and a modified core.

Main Mister: You can grab a pre-compiled version with the changes from the releases directory here: https://github.com/zakk4223/Main_Mister_ZQol

Thanks ! I was expecting to need both - and to be fair, I was more interested in seeing how many places needed to be modified. The commented-out "ReadSubcode" routine looked like a nice little easter egg until I realized that wasn't getting data from anywhere or pushing it anywhere. I can write something to read from the *.sub file, but have no idea about *.chd files. Then feeding it across to the core is another matter (but once in a FIFO, I understand how to represent it within the core).


@rhester72:
Your command-line rip worked great, and grabbed data - well, at least *some kind* of data into the CHD.
But without having software actually play it back, one cannot be sure that it's *correct CD+G* data. This was what I was looking for.

Google is full of incomplete and misleading information on lesser-known facts like this, including things like "VLC plays them", which *I* tried. By the way, it doesn't work, and doesn't claim to. But it was also repeated here as though it were a fact (without verification). I have been seeking facts from the beginning... not beliefs stated as though they are facts.

I'm happy to admit that I was wrong about drives being able to read the subcode, now that I've seen the end-to-end.
Oh, and Mednafen (PCE driver) also plays them - at least the CloneCD-based *.sub files . But Mednafen needs to be started by pointing at the *.ccd file, not the *.cue file.

[rhester72]

@zakk4223 I checked git and didn't see an update to Main_MiSTer code...any chance you could point me in the right direction?

[zakk4223]

In that repo I linked there's a directory 'releases', that has an updated MiSTer_20210703.
If you just want to compile your own there's a 'patches' directory, use the one that starts with '0006'

[rhester72]

Weird...when I look here:

https://github.com/zakk4223/MegaCD_MiST ... r/releases

or here:

https://github.com/zakk4223/MegaCD_MiST ... e/releases

all I see are rbfs.

[dshadoff]

In that repo I linked there's a directory 'releases', that has an updated MiSTer_20210703.
If you just want to compile your own there's a 'patches' directory, use the one that starts with '0006'

Zakk4223, looking at your patches, I see that much of the plumbing for the MegaCD core was apparently already in Main_MiSTer, just needing to be uncommented (unlike TGFX), though CHD in particular was not. Are you planning to commit a pull request soon ?

[zakk4223]

Weird...when I look here:

https://github.com/zakk4223/MegaCD_MiST ... r/releases

or here:

https://github.com/zakk4223/MegaCD_MiST ... e/releases

all I see are rbfs.

There are two repos linked in my original post, use the one in the sentence about 'Main Mister:'

[rhester72]

OK, I must be an idiot. LOL

MiSTer md5sum:fbb8056d00cb5cfb37620859be1ba880
RBF md5sum: e3353d9c956a47f5131bdc04bbca0128
BIOS md5sum: 14db9657bbaa6fbb9249752424dc0ce4 or 310a9081d2edf2d316ab38813136725e

Region is set to Auto, CD Audio is set to Unfiltered...discs continue to play fine but no CD+G (from CHD).

[zakk4223]

In that repo I linked there's a directory 'releases', that has an updated MiSTer_20210703.
If you just want to compile your own there's a 'patches' directory, use the one that starts with '0006'

Zakk4223, looking at your patches, I see that much of the plumbing for the MegaCD core was apparently already in Main_MiSTer, just needing to be uncommented (unlike TGFX), though CHD in particular was not. Are you planning to commit a pull request soon ?

At some point yes, after a bit more testing. I'd also like to figure out what the 'CD+G channel' next/prev actually does. It seems to go up to the number of tracks on the cd. Is there a mode on real hardware where it plays no audio but just the CD+G graphics? Playing audio of one track and CD+G from another seems nonsensical to me based on how subcode data is stored.

[dshadoff]

At some point yes, after a bit more testing. I'd also like to figure out what the 'CD+G channel' next/prev actually does. It seems to go up to the number of tracks on the cd. Is there a mode on real hardware where it plays no audio but just the CD+G graphics? Playing audio of one track and CD+G from another seems nonsensical to me based on how subcode data is stored.

Since the subcode information is interleaved on disc with the audio, it would be impossible on real hardware to display CD+G graphics of one track while playing the audio of another.

I'm not familiar with the capabilities of the MegaCD CD+G player though, as I never owned one back in the day.
In any case, where are you seeing "'CD+G channel' next/prev" ? Is it on the player app, or in the code, or somewhere else ?

[dshadoff]

OK, I just looked at the CD player on my MegaSD on my MegaSG... You are looking at the upward- and downward-pointing triangles, right ?
Those appear to be selective about what subset of CD+G data is used for the render.

For example, on "Talking Heads - Naked", CH01 plays all of the data (as far as I can see) - including the upper half of the screen (chord progression and one line of lyrics), as well as the lower-half of the screen (several lines of lyrics in a larger, more elaborate font)... whereas any "channel" above that would display only the lower half lyrics.

[zakk4223]

Interesting. With my mister modification it doesn't do anything, but I'm only trying with Information Society and Rock Paintings. Maybe they only have one channel anyways.

[rhester72]

Interesting. With my mister modification it doesn't do anything, but I'm only trying with Information Society and Rock Paintings. Maybe they only have one channel anyways.

I'm pretty sure that's correct. I've never encountered a disc with more than one channel of CD+G data. Perhaps dshadoff can provide a test image of his disc...I didn't know what the hell those buttons did back in the day because they didn't seem to do anything LOL

[dshadoff]

Interesting. With my mister modification it doesn't do anything, but I'm only trying with Information Society and Rock Paintings. Maybe they only have one channel anyways.

I finally got a chance to apply the patch to Main_MiSTer and try this out... looks pretty good ! (for cdrdao -> CHD rips)

However, I was wondering whether you were expecting it to work with CloneCD-type rips... it doesn't. Or rather, it plays them as audio CDs only.
The changes to Main_MiSTer would seem to imply that it should be opening the *.sub file, and reading from it though...

[dshadoff]

Oh, my mistake - I applied the patch from a couple of days ago, and just now noticed that you had updated it.
The new one appears to work.

Thanks !

[zakk4223]

I can also confirm the 'cd+g channel' is a pure 'software' feature. It works with no changes to the core or main (other than all the changes to support CD+G).

I'll assemble the required PRs in a day or two; soon everyone will be able to enjoy facts about Minnesota while listening to Information Society

[rhester72]

@zakk4223 Do you want more test rips? I had another disc show up yesterday.

[dshadoff]

I found some technical information about how the graphic data is encoded into bytes (in addition to how the subcode is encoded on the disc).

This won't be necessary for playback, as the software players already implement the playback protocol - but since the list of CD+G discs that exist is pretty short, if somebody wants to see what the technical capabilities are, and encode a disc, some technical information is here
https://web.ncf.ca/aa571/cdgfaq.htm (Note: lots of broken links)

[rhester72]

This might be the longest disc I've ever ripped - 19 tracks, 69:46:15.

https://www.rendezvo.us/cdg_try2/Little ... Hoy%21.chd

[rhester72]

OK, finally got it working after doing my own Quartus build - I think I picked up an earlier prebuild before things were ironed out.

Is what appears to be random decoding and/or paint errors a known issue? No matter what disc I choose (or how many times I cold restart), a minimum of one (but often 2-4) vertical 'strips' anywhere from 2 to 8 'blocks' high on various parts of each screen are either flat-out corrupt or "leftovers" from a prior screen (but in the wrong place!). Not quite sure how to explain it, I can make a video if it'll help.

[Moondandy]

I didn't know CD+G was a thing until I read this thread, have ordered a copy of this Jimmi Hendrix one:
https://www.discogs.com/Jimi-Hendrix-Ex ... ase/589570

I was planning on doing some testing on various CD based consoles so when I am doing it will try this on the ones I have and document which can actually play these things.

[dshadoff]

Just be careful when ordering; many of the circa-1990 discs have both CD+G version and non-CD+G versions (and the CD+G versions are getting harder to find as time goes on).

Of course, there are also apparently karaoke CD+G discs...

[Mellified]

I didn't know CD+G was a thing until I read this thread, have ordered a copy of this Jimmi Hendrix one:
https://www.discogs.com/Jimi-Hendrix-Ex ... ase/589570

I was planning on doing some testing on various CD based consoles so when I am doing it will try this on the ones I have and document which can actually play these things.

I played that disc on my Sega CD back in the day. It added some interesting visuals to the music. Would be nice to see it working again!