Secure ripping

Discuss the current and future development of Max.
darkcore
Posts: 2
Joined: Thu May 25, 2006 9:51 pm

Post by darkcore » Fri Jun 02, 2006 4:04 pm

ye wrote:
sbooth wrote:I can still access the subchannel data, which contains some data which can be used for error checking and correcting. More on this to come.
I looked around on many sites to get infos about the data structure on the Audio-CD. The info is often contradicting :( I fear I have to have a look in the Red Book if I have some time and get access to it :( :(

But up to now I am quite sure that the parity data is NOT provided in the subchanels. The most convincing argument is the lack of amount of information:

To 24 data bytes there are added 4 bytes of parity information in the first encoding step (in most places called C1 encoding), and 4 bytes of parity information in the second encoding step (in most places called C2 encoding).

So for the 2352 bytes of audio data per sector you get additional 784 bytes of parity data, you must have access to, to do your own error correction. This amount of additional bytes does not appear in your list of available data.
294 bytes of error flags (an array of 2352 bits, with ones where C2 errors were detected)
96 bytes of subchannel data (*I assume this is a Typo and is 98*)
This is just half of this data. So if we are lucky we can do one layer of decoding (of two encoding steps) ourself. But more likely , taking in account the naming of these data, it contains other information.
Not sure if this document is helpful or not but I found this: http://www.yates2k.net/cdnotes.txt

and this document about CD+G disc playback has some subchannel info but it mentions the subchannel data being 96 bytes too, hmmm:
http://www.jbum.com/cdg_revealed.html

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Post by sbooth » Sat Jun 03, 2006 5:16 am

The more I read the more I think you are correct- the subchannels do not contain the parity information. I think ye is right again- there really is no substitute for the Red Book.

On a brighter note, I was able to get C2 error detection working. It's currently just a hack onto the basic ripper that outputs a message to the log when a sector has C2 errors, but it's a start.

User avatar
ye
Posts: 20
Joined: Thu May 11, 2006 7:43 pm

Post by ye » Sat Jun 03, 2006 7:22 am

Has anyone the exact title, author, publisher, ISBN and/or ISSN number of the "red book"?

I tried search of library catalogs with "red book" and variants of "Audio recording - Compact disc digital audio system" or "IEC 609" but got nothing of which I think it is the red book .

I tried the nationwide catalog, the British Library and the Library of Congress. Come on, that is impossible, it must be somewhere out there, at least in the catalog even if it is not accessible.

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Post by sbooth » Sat Jun 03, 2006 4:33 pm

I had an idea for a possible way to check for errors- I wanted to bounce it off a few people here and see what the response was.

The Q subchannel in the program area (the so-called "DATA-Q") contains information that I think might be usable during ripping. For at least 9 of 10 successive CD frames it contains:
  • track number
  • index
  • MSF of the current time
  • zero
  • AMSF
Since it is possible to retrieve the Q subchannel along with the audio data, would checking 1) the Q subchannel for well-formedness and 2) the MSF (minute-second-frame) position against the sector that was requested give some idea as to the quality of the disc being read?

maya
Posts: 26
Joined: Sun Mar 26, 2006 8:33 pm

Post by maya » Sun Jun 04, 2006 5:17 am

sbooth wrote:I had an idea for a possible way to check for errors- I wanted to bounce it off a few people here and see what the response was.

The Q subchannel in the program area (the so-called "DATA-Q") contains information that I think might be usable during ripping. For at least 9 of 10 successive CD frames it contains:
  • track number
  • index
  • MSF of the current time
  • zero
  • AMSF
Since it is possible to retrieve the Q subchannel along with the audio data, would checking 1) the Q subchannel for well-formedness and 2) the MSF (minute-second-frame) position against the sector that was requested give some idea as to the quality of the disc being read?
I wouldn't mind to see if Max would be able to read all indices on a CD. I have a CD which is 2 30-min tracks, but each track is made up of smaller parts. EAC can see the incides of the smaller parts, but as of right now, Max does not.

Perhaps this Q-DATA retrieval is a good idea.
“Unless you’ve seen KISS live, you don't understand the band.” —Paul Stanley, KISS. (2003).

User avatar
ye
Posts: 20
Joined: Thu May 11, 2006 7:43 pm

Post by ye » Sun Jun 04, 2006 6:36 pm

sbooth wrote:I had an idea for a possible way to check for errors ...
If I interpret the information form http://web.usna.navy.mil/~wdj/reed-sol.htm (which I thing is one of the better sources out there) correctly we have:

1.) the sub-channel data is not (C1, C2) encoded, and hence also not corrected, as the audio data.
I suppose the high redundancy (by high frequency of almost identical data) was considered to be enough in combination with some checksum info (see below) to detect the bad blocks.

2.) the sub-channel data is not interleaved.

As a consequence the audio data might be correct even if the sub-channel is not. This does not hinder us to use the sub-channel to judge the disk quality, but the result might be worse than the situation really is.

The result of the test you proposed may be one possibility to do so, if not the decoding black-box remove inconsistent Q-channel data.

Wikipedia germany has some more detailed infos about the use of the Q-channel bits http://de.wikipedia.org/wiki/Audio_CD. If the there mentioned 16 crc-checksum bits can be (partly) used to check the consistence of the Q-channel data this would be a more straight forward way to do so.

RonaldPR
Posts: 433
Joined: Tue May 30, 2006 8:27 am
Location: Amsterdam, Netherlands

Post by RonaldPR » Mon Jun 05, 2006 4:55 pm

With all the problems reported with "comparison ripping" I would suggest to release a next version of Max now, with "paranoia" set as the default and "comparison" labelled as "comparison (experimental)" or similar. That will provide time to develop "secure" ripping further without causing unnecessary problems for the average user.

persept
Posts: 1
Joined: Mon Jun 12, 2006 6:44 am
Location: California, USA
Contact:

Post by persept » Mon Jun 12, 2006 6:53 am

this q-data and etc. seems like alot of hassle to me. I think that it would be easyer just to use cdparanoia for the ripping. You could rip it multiple times, and compare the number of errors cdparanoia gets for each rip, and then use the rip with the least errors. Correct me if there are problems with this approach.

on a side note: i tried ripping a track using the comparison ripper and then cd paranoia. I checked the checksums and they were identical.

Steve
Posts: 5
Joined: Fri Aug 18, 2006 12:08 am

Post by Steve » Mon Aug 21, 2006 1:18 pm

sbooth wrote:...there really is no substitute for the Red Book.
sbooth, Do you still need the red book for work on the secure ripper? Wikipedia says that you can get a PDF for $210. Or possibly get it from Philips for $100.

I know you are against monetary donations, but a collection to purchase one of these seems appropriate to me.

Steve

User avatar
Fuga
Posts: 391
Joined: Mon Jun 05, 2006 8:30 pm
Location: Texas

Post by Fuga » Fri Sep 22, 2006 5:40 pm

AGH!!!!!!!!

I just setup EAC on my new Dell laptop (well, my wife's, but she graciously gave me an administrator account). It has a DVD burner. It doesn't cache audio!

Fat lot of good it does my Mac side.

Just had to vent. Oh, and to point out that the conventional wisdom that all new drives cache is apparently false.

khead
Posts: 66
Joined: Mon Jan 23, 2006 3:40 pm

Post by khead » Fri Sep 22, 2006 9:15 pm

All new drives do not cache audio, and having a drive that does not cache audio is not a panacea to secure ripping on the Mac.

I Have 3 drives that don’t cache audio, and they give varying levels of rip quality with Paranoia.
The stock Matshita superdrive in my G5 iMac doesn’t cache, and it’s a pretty lousy drive with scratched disks. Paranoia makes it quite a bit better , but it can still let some clicks, pops and skips get through without notice.

Most NEC’s don’t cache. I recently bought a 3550 thinking it might be my ticket to ripping nirvana, but sadly it was not -- Still can let some skips get by on damaged disks.

The stock Pioneer 106 superdrive in my old eMac is considered a caching drive by EAC, yet works better with Paranoia than either the Matshita or NEC.
I’ve user this drive with Paranoia a huge amount, and I’ve never seen it let me down by letting a skip get by --- Even on heavily damaged disks.
Still get some minor clicks and pops with it though.
Not at all bad.


The whole caching issue is an open question as far as I can tell.
For the most part whether a drive is considered caching or not has been based on how it is reported by EAC - and exactly how well it does this is the subject of some debate.
Also EAC uses a point above 0KB for it’s cut off point for its definition of catching/non-caching - 64KB or so ... I think.

How exactly this applies to Paranoia’s ability to handle audio caching is a question in my mind. The fact that my Pioneer drive is reported by EAC to be catching - and therefore most likely catches at least 64KB, and seems to work so well with Paranoia leads me to suspect that Paranoia can handle 64KB of catching.
Or something else is going on....


Also - I just got an LG H10 drive yesterday. It’s reported as non-catching by EAC - and reported as catching 37KB by the more accurate, but less widely used Cache explorer program. From what I can tell so far, it works quite well with Paranoia, and is very good with scratced disks.
Crossing my fingers that this might be my golden drive.

User avatar
Fuga
Posts: 391
Joined: Mon Jun 05, 2006 8:30 pm
Location: Texas

Post by Fuga » Fri Sep 22, 2006 9:57 pm

Great report. Thanks.

khead
Posts: 66
Joined: Mon Jan 23, 2006 3:40 pm

Post by khead » Fri Sep 22, 2006 10:36 pm


someone
Posts: 7
Joined: Mon Feb 13, 2006 5:47 am

Perhaps cdparanoia is already handling the issue of caching

Post by someone » Thu Apr 12, 2007 5:07 am

From this mailing list archive:
http://lists.gnu.org/archive/html/libcd ... 00008.html
>How big is your drive's cache? There's a setting in the
>cdrom_paranoia_t that you pass to paranoia_read() that specifies how
>many sectors cdparanoia needs to read to exhaust your cache.
>Specifically, it's cdrom_paranoia_t.readahead.
>
>cdparanoia is written in a way that assumes everything is broken,
>because it usually is in practice. Drivers and kernel can cause
>dropped samples, drives almost never support the features they claim
>to support, etc. Or, to your point, drives don't always obey FUA (or
>its implementation in the driver or kernel may be broken). Thus the
>way cdparanoia is designed to handle drive caches is to increase this
>readahead value so that it exhausts the drive's cache. This approach
>ends up being more reliable.
The post suggests that cdparanoia has two ways of dealing with the read cache: using the FUA flag and increasing the readahead value.

In any case, you might be interested in the libcdio project, which attempts to create a crossplatform library for issuing MMC commands among other things.

someone
Posts: 7
Joined: Mon Feb 13, 2006 5:47 am

Post by someone » Thu Apr 12, 2007 5:26 am

From the developer of cdparanoia:
http://slashdot.org/comments.pl?sid=108647&cid=9242997
ATAPI finally added packet commands for dealing with cache management on ATAPI drives, just like SCSI always had (but most drives just ignored). ..Or you can increase the cache thrashing constant and rebuild. These days computers have more than 8 meg, it's probably worth doing ;-)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest