To the moderator: Delete this posting if you think it is too technical or theoretical ...

But for those who are interested in getting about 100 MB more DATA onto their CDs, read on.

First let me say: You *MUST* have a *VERY* good AUDIO reading drive (perfect DAE). If you don't have such one, don't waste your time reading this post!
All others can try to record DATA as AUDIO:
Because Audio-CDs are using less error correction than Mode1 Discs, you can store more usable data on it.

It is good to get the driver CDFS.VXD first. It allows you to access AUDIO-CDs directly from the explorer. Search for it on the web and replace it with the file located in the folder %windir%\system\iosubsys.

Now get WinRAR and compress (or just store without compression) all the files you want to have on your CD.

Create a small file containing digital silence with e.g. Cool Edit. Lengh 0.1 seconds or about 4000 samples (cut the rest if you're getting to much silence). Save this file as RAW-PCM 44100 Hz, 16 Bit Stereo.

Then merge your silence-file (it could contain noise, too) with the created RAR-archive - and this again with the silence-file:

example: DOS-Prompt: copy /b silence.raw + test.rar + silence.raw test_cdr.rar

You still get a RAR-File but with silence @ beginning AND end.

This resulting RAR-File you can burn with CDRWIN and a cuesheet which looks like:

FILE test_cdr.rar BINARY
TRACK 01 AUDIO
INDEX 01 00:00:00

The RAR archive can be about 750 MB in size depending on the CD-R you use (this guide assumes the use of a 74 min CD-R).

The burnt image is a pure audio-cd containing DATA. Please don't try the play it with your CD-Player - it doesn't sound really good. Also the autostart feature of windows is DANGEROUS!!. It could play the disc as audio.

To get back your DATA, you can open the CD with WinRAR again (Folder <drive>\Stereo\16Bit\44100Hz\Track01.wav) and extract all your files. That's it!

Why I use WinRAR:
Because CDFS.VXD interprets the CD as audio, it adds a WAVE header which MUST be ignored. Sometimes WinRAR displayes a message: RAR-Header is corrupt!. Ignore it, too ;-)

Why I add a silence file:
Because almost every CD-ROM drive has an offset. The silence @ beginning and end "protects" the DATA because the offset always will be smaller than the added file. But don't make too big silence files, WinRAR won't recognize the archive anymore!!!

Why I use CDFS.VXD:
Because it's annoying to have to copy the whole CD to get just a little file.

Tried with UltraPlex, PlexWriter 12/10/32S and Toshiba SD-M1401 (doesn't always work :-( )

At last I must say that the data security is reduced, of course.
And it is only experimental. You need *VERY* good medias and *VERY* good hardware. Try it on CD-RW if you can. So you don't have to waste your valuable CD-Rs.

The reason of this is because there is another kind of error correction on audiocd's. I'm afraid that just one scratch on the surface and the complete data (all 750mb) will be unredable (try an old cd with EAC and look at the error correction.
Doesn't look a good idea to me

To be hounest; this is a nice idea. I wouldn't use it because of several items (secuirty, taking too much time etc), but besides of that it really is nice .

Just one question: how did you come up with this??

Wouldn't it be easier to just use 866MB CD-R's



The idea sounds pretty good but there are some problems like you already explained. There's no guarantee it'll work and on top of that the error correction data is there for a reason. Like Crowley already mentioned: the disc will become useless when scratched.

@Dee-ehn
I like to experiment and so some day I read this excellent site "The truth about offsets". And I thought that it must be possible to burn AUDIO as DATA.

There are so many rumours, that copying AUDIO CDs @ high speed would decrease the sound quality. This is pretty a good proof that this isn't true if you have good hardware.

Of course you can use 99 min CDs but because they use the lead-in sectors of the disc, errors can occur, too.

At least, with WinRAR you will know if something failed, because of its CRC check.

Some time ago, before I tried this audio-method, I were looking for a tool that allows me to record DATA as Mode2/XA (2336). With this you would have a filesystem, too, esay access, and still more space to store data. OK, decreased security again, but it is still safer than audio. Even the PSX uses it ...

It seems to be a good idea, but, apart from the ERROR CORRECTION problem, if i want my data back, I have to uncompress a 750 MB file, dont' I? I think it's a bit annoying... Anyway, i may do it when i have a bit of time.

K, but what's the real size of these CD-r's?? I'll give ya a small calculation (let me try to explain it in a short and clear way):

CD-DA encoding at 16 bits:
-Every second = 44.100 kHz x 16 bits x 2 channels = 1.411.200 bits (or 176.400 bytes).
When CD-DA format data is put on a CD, every second of music consists of 75 frames. So every frame contains 2352 bytes.
Now, how many bytes would that mean for a 90-minute CD-R??:
2352 bytes x 75 frames x 60 seconds x 90 minutes = 952.560.000 bytes
= 930.234,375 kbytes
= 908,4 Mbytes
Tadaaa! Here you have 908,4 Mbyte instead of 870 Mbyte!!!

Now, for Mode 1 and Mode 2 data, the calculations are slightly different:
Mode 1 : 2048 bytes per frame
2048 bytes x 75 frames x 60 seconds x 90 minutes = 829.440.000 bytes
= 810.000 kbytes
= 791,0 Mbytes

Mode 2 : 2336 bytes per frame
2336 bytes x 75 frames x 60 seconds x 90 minutes = 946.080.000 bytes
= 923.906,25 kbytes
= 902,3 Mbytes

Just some small calculations I've done for ya... So if you want to calculate the actual capacity of your favorite CD-R brand, then take a good look at it's size. Nice tool to determine is the CDR-Identifier from www.gum.de
Ohw, and a lot of people tend to think that 1 kilobyte = 1000 bytes, but that's not true!! 1 kilobyte = 1024 bytes, and even so 1 Megabyte = 1024 kilobyte

Contents as posted originally in this message on CD-Freaks .

@tonilope
If you want back all your data, then you'll have to uncompress the whole 750 MB file, yes.
But if you want only parts of the archive, you can access them seperately. But make shure, you have not selected "solid archive" on creation, because then WinRAR has to read the hole file from beginning until it reaches your requested data.

@CrazyJay

In the best case you could have

2352 bytes x 75 f x 60 s x 99 min = 1047816000 bytes = 999.28 MB of data stored as audio.

But forget it to read such a disc to the end without errors ...

Interesting test! But I guess there is no real practical use, because like said before almost no error-correction is used anymore, one little mistake by your reader or dustparticle on the cd would make the data not readable...

Your solution leaves out the ecc/edc error-correction mechanism. This way you have to rely on CIRC error-correction (interleaving + parity checks). This is not a good error-correction mechanism for data... for audio there is no problem because in case of unrecoverable errors techniques like interpolation or in the worst case muting of the audio bitstream is used. Muting or interpolation is not really appropriate for data...

But I like your experiments, so keep up the good work!

This test does indeed show that highspeed reading of audio doesn't give problems because your test showed that the absence of ecc/edc was no problem for the data encapsulated in audio. But another problem which may arise is the jitter-problem (=timing-information problems). I don't know a lot about this subject, but do know that keeping up the correct time-information is more difficult at high speed.

Most 99 min CD's are 99:05 or similiar. However, the 1 GB barrier can never be broken, only approached with this method. So you could store any amount less than 1 GB.

Perhaps even more could be squeezed out by using the Subchannel info.

Maybe one could create a program (stored normally on the CD) that would autoload on insert, read info in an audio track (presumably also on the CD), and create a virtual drive with all the files on it, and a seamless decompressor. So you could store 1GB+ of uncompressed data (though the actual data on the CD is compressed). This might be the most a single CD can store.

Little-Endian has done a great thing.

Ok, One thing I keep reading is "Just one scratch and the CD is useless. Now call me crazy but isn't that the case with any CD?

As I see this, this isn't something that everyone would want to use in a normal situation, but if you have anything you REALLY don't want anyone to see, then this might be a good option. Lets not forget that you don't HAVE to burn it to a CD, an ISO image on the hard drive would work as well.

My question are thus:

Does one REALLY need the cracked CDFS.VXD to access the data, or does that simply make it easier to access the file? Can one instead "Rip" the data using standard software (CD-Paranoia, CDex, or whatever) and then follow the steps to finish processing the data?

If not, what options exist to do similar things under NT/2k/XP/MacOs/*nix?

Skruddgemire

Normal error-correction methods are used to prevent a cd becoming useless after just one scratch... or fingerprint or dustparticle, etc. These mechanisms work remarkably well considered what an avarage cd 'has to go through' during its lifetime.

But you don't need that special CDFS.vxd, any normal ripper would also do the trick. Afaik this CDFS.vxd is only available for Win95/98.

Wouldn't it be possible to even use subchannel-Data? That would be some more bytes to use.
I don't know if this can be done at all, I was just thinking about what data can be stored on a CD

Yeah, subchannel usage would be great, but I think it's impossible. At least for the Q-Subchannel (because it's used for navigating, I think). Maybe you can use the subchannels R-W. But that doesn't give much space to store data in it.

Also, subchannels aren't really "error-protected".
Example: Read a disc with CloneCD, subs reading enabled, twice.
And then compare the SUB-files with fc /b or any other tool.
There *ALWAYS* will be differences, no matter, how often you read ...

There is only a error-detection mechanism based on CRC for subchannels... I guess CloneCD doesn't use these 16bit CRC while reading because sometimes protections are created by using 'illegal' subchannel entries. In that case the CRC check won't match, but it is done on purpose. I guess that CloneCD uses the CRC value while writing the image if you don't tick "don't repair subchannel data"...

There is already an interesting project going on looking into burning 800MB of MPEG4 variant video onto an 80 minute CD-R. Please check this thread.

800MB Video on 80 Minute CD-R

I am gonna see if I can use this method to put a divx file larger than 700MB onto an 80 minute CD-RW and see if it plays back.

Let you know how it goes.

OK I have followed your instructions and have managed to burn the file fine. I can't seem to read it back though. It's shown as a .cda file on the CD. WinRar barfs when I try to open that file. Says the file in an unknown file format or damaged. cdfs.vxd is in the iosubsys folder but how do I know it's being loaded/used? I use Windows XP BTW.

the alternate cdfs.vxd doesn't work with Windows XP/2000.

You must rip it and then extract it with WinRAR.

Little-Endian, apparently someone has been thinking the same thoughts as you. Check out http://webs.ono.com/usr016/de_xt/mcf.html.

I've done it and it's great !!!

@SirDavidGuy

Yes, I have seen it yesterday @ the doom9.net page.
It allows you to record *ANY* file in MODE2/Form2 mode.
If have tried it:
Unfortunately windows adds a CDXA-RIFF-Header to the recorded file on reading. But you can extract the file with the tool included in the package or with Isobuster.
Maybe one day there are filters to access the file "directly", so that you don't have to copy the entire file to the hdd first (like CDFS.VXD). But anyway: This is tool is great!!