Sub Channel Data

[Nikos]

Each clone program usually has its own drivers. The API changes, so I guess the format they use for the files is mandated by the API.

Also, there might (note, might, not sure) be differences in byte-ordering. Although I don't see a reason why a PC app would use anything else than little-endian, it might be an issue.

EDIT:
I don't think the apps encrypt the data. There's nothing to hide, after all.

[MonkeyMonkey]

Makes sense to me that they wouldn't encrypt the data.

Up untill now, I've been assuming that ReadCD packs all the subchannel data at the end of each sector (in the image). This is how it appears in a Hex editor, however, there may be more information in the actual sector which I'm currently investigating.

Do any Copy Protections store error checking information in their subchannel data?

[MonkeyMonkey]

Updates

Well, after a lot of tinkering around, and learning more about how the subchannel data is stored I have had SOME success.

I wrote my own code to DeInterleave the subchannel data, which seems to be working succesfully. The resulting data matches the data in the .SUB files of Clone CD.

I'm writing a small, inflexible program to confirm this. It will take a RAW input (R-W Raw read from ReadCD) and will spit out a .SUB file.

Will post if I have success.

This still leaves me to ponder how the data is organised in the Alcohol files, my next challenge is to investigate that.

[MonkeyMonkey]

Current Findings
Alcohol 120% MDF files contain all CD data including Sub channel data. The Sub channel data is coppied at the end of the 2352 byte sector (2352 + 96). This data is a RAW copy and has not been de-interleaved. The sub channel data in these files sometimes contains all 0's in the P channel OR all 1's in the P channel (or mostly). I believe this corresponds to CD encoding.

CloneCD seperates the Sub channel data into it's SUB file. CloneCD also performs a software deinterleave on the data prior to placing it into the SUB file. There are mostly 0's in the P Channels. The 1's found in the Alcohol 120% P-Channels do NOT correlate in the CloneCD sub channels.

Blindwrite does it's own thing, I haven't looked into those files. There are people out there reverse engineering Blindwrite files, I'm aware of a project on sourceforge that converts these to ISO's.

I've written a software De-interleave program (extremely roughly, it doesn't take command arguments nor performs any input / error checking). The above findings assume that this program of mine works.

ReadCD is capable of Raw reading, however, I don't know if it's as thorough as the first two programs.

I've compared Sub Channel data from all three programs (CloneCD, Alcohol and ReadCD) using the DeInterleave program, and there are many similarities between the data but they're not identical. I remember reading that consecutive reads can yield diffrent data for Sub Channels, but there are some strong differences as well. As mentioned, each software uses it's own driver to read the data, but would you expect large changes in the data?

I'll start testing consecutive reads using the one program to see if there are strong differences as well.

[Underheaven]

MonkeyMonkey

Very neat stuff. You could also try consecutive reads on different hardware with a known program like Alcohol or CloneCD.

[Nikos]

When reading in raw mode, you can't be sure that any data you get is actually correct. Alcohol and CloneCD performs a software check. However, the actual algorithm for performing data integrity checks on raw sectors+subs is beyong my knowledge.

[MonkeyMonkey]

Sounds like this could be that "Reed-Soloman" algorythm I've heard of. I guess that's not an option then.

I've just re-read the post about each company using their own driver, this is a good point and could yield differing results. Part of me still wants to hope that the data output should still be the same.

Well, this is getting tricky now. I guess this is probably why an open source version isnt' really available, no one's willing to donate a red-book to these folk?

I'm not sure what I do from here on, I have a rough roadmap:

First I want to yield similar results to Alcohol 120% using readCD. At least the ISO data should be the same. I then want to investigate the various options in Alcohol and see what compatability readCD has (as well as review the mmc standard, with some assistance). There may be some commands not being utilised by readCD.

If I can find a way of replicating the Alcohol 120% settings (as best as possible) and obtaining similar results, then that should be successful enough. Though I may note be able to record all protection and subchannel data succesfully, there are those people at DT and other places who can emulate the security and hopefully we'll do without.

Next step is to find out what the recommended Alcohol settings are for various copy protections, and code that into an app. I want the application to first Identify the copy protection and then copy the cd as appropriate. I want the output files to closely mimic alcohol files, so it can be used with DT.

Timeline? Well, I've got some time off over christmas, I hate letting these things drag out so long. I also realise that my first ambition of an open 1:1 copy program is not as realistic as I hoped it would, I still want something that does a bit more than ISO copying which is meaningful. I might check out some open CD+G rippers as well.

Anyway, I'm still all talk at the moment. I do look forward to spending some more time on this again shortly.

[phoenix]

If anyone has reverse engineered Alcohol or blindwrite files (mainly the header files), I'd appreciate picking your brains.

Since Alcohols MDS\MDF format was a joint development project with DTools, asking a question like this on this forum is a little stupid. Reverse engineering is not legal.

[MonkeyMonkey]

Thanks for your information, I was not aware that reverse engineering files could be illegal. Despite my personal opinions, law is law; I will research this further.

If you could please direct me to an appropriate location (either government legislation or even a copy of Alcohol 120% license agreement) where it states that reverse engineering file formats is illegal, I would appreciate it as it would expedite my research.

It's been a while since I've spent time on this project, I want to spend some time reading the MMC specs (since I believe this is used with read-cd).

I will admit that I'm loosing momentum on this, as I'm discovering more and more which is making this rather cumbersome.

I will shortly post whatever code snippets I've collected which may help someone else more experienced or anyone else who wishes to continue this. I'll also contact the developers of read-cd and see if they're interested in this.

[Jito463]

Straight from the Alcohol Software EULA. Relevant portions are highlighted in bold.

2. PROTECTION OF SOFTWARE.
You agree to protect the Software and the Documentation from unauthorized copying or use. You acknowledge that the source code for the Software and other trade secrets embodied in the Software have not been, and are not going to be, disclosed to you. Modifications of, additions to, or deletions from the Software (including any deletion or addition of code) are strictly prohibited. Except as specifically permitted in this Agreement, you agree not to, directly or indirectly, (1) use any Confidential Information to create any software or documentation that is similar to any of the Software or Documentation; (2) reverse engineer, disassemble or decompile the Software; (3) encumber, transfer, sublicense, rent, lease, time-share or use the Software in any service bureau arrangement; or (4) copy (except as provided herein), distribute, manufacture, adapt, create derivative works of, translate, localize, or otherwise modify Software or permit any third party to engage in any of the acts proscribed in clauses (1) through (4). You agree not to remove or alter any printed or on-screen copyright, trade secret or other legal notices contained on or in the Software or the Documentation.

[MonkeyMonkey]

Thank you, I appreciate the effort to find the reference. I may have misunderstood these statements to refer to execution binaries and libraries. Not generated files.

This leaves me in an awkward position then. I will check the Clone CD EULA for a similiar statement, though I suspect that it's a standard agreement.

My next path is to then develop something different then. My aim would be to split raw data from subchannel data into seperate files, but emulation is still a problem. Got to run, but i will put more thought to this later.

I also now understand how the B52 to ISO project is probably legal, they are not recreating, just reading and then outputting to a new format.

G

[Jito463]

That's part of the reason why you don't always see every company support all the different formats out there. For example, Alcohol still does not support Blindwrite 5 images (it can technically be possible to mount them in the virtual drive, but burning them is another matter). It all depends on the original author of the format and how much information they're willing to release about it.