xcd stuff

[Psymaster]

I was reading some stuff about xcd. From what doom9 says, ordinary 700MB discs can contain up to 800MB of video-audio with this method.

I was thinking, what if the burner supports 90 or 99 min CD-R's? On tom's hardware it says that they could fit 900MB on one 99min disc and it would play on most cd players and in all pc's. Is it possible to use them as xcd's? Knowing that these discs have some problems on their own, would xcd cause additional ones? Has anyone tested it?

[vinouz]

as far as I know on a 900mb cd XCD gives some 1GB data.
the problem reading/writing XCD discs is the same writing conventionnal ones. On an XCD, the burner doesn't physically write more bytes, but some of them usually devoted to error correction get taken back for data. So you have less error robustness, but as video can handle errors (that would make a little difference at a very little portion of the whole film, and no particular data but structural data is crucial) more than pure data such as a program, which can't even allow a bit of error, it's more interesting recuperating this error control data in favor of more information, so more quality describing the video.
So that's it. We get more data, less surely, but in our case we need data more than exactitude of it.
but at the surface of the disc you exactly write the same amount of pits and lands (you burn the same distance).
Here it is, if I'm not that mistaken grossly.

So, no more problems writing 1Gb video CDs if your burner can handle 99mn CDs.

Vinouz

[SirDavidGuy]

On an XCD, the data's only protected by CIRC, which can't correct too many errors.

Using Subchannels would be very helpful for XCD's, storing RS codes in them, for the drives that can read it.

www.eccpage.com has some great info on them.

[Psymaster]

So, no more problems writing 1Gb video CDs if your burner can handle 99mn CDs.

:) :) :) Which most recent burners can!!!

[DeXT]

@SirDavidGuy: yes we already thought on the possibility to put additional RS encoding information into subchannels, the only problem is, to be able to read these and make use of them you must read the CD in RAW format (much like CloneCD does) so this requires either special support in players (which is ugly) or a new IFS driver (which is very hard). This could be more suitable for a format requiring a new IFS driver afterwards, such as MCF-CD (which is aimed at any format, not just DShow-supported ones).

On the other way interleaving is a good idea, althought it requires some additional information in the header to make the reader realize it's interleaved content. Current XCD implementation is not very friendly to this since you would need to keep the *.XCH file to be able to play the movie, otherwise you'd get trash (current implementation makes it optional, just for backup purposes). This doesn't mean it can't be done of course (we have some room on subheaders to put an interleaved flag).

[mustaneekeri]

I have a LG's burner which is capable of 99:59:99 of burning. Allready tested the "XCD" method with 99min disks. I made a rip (.ogm) which was about 970MBs. The resulting disk played fine in my Lite-On LTR-163 DVD drive. Any drive capable of reading 99min disks is capable of reading 99min XCD disks, therefore there is no additional problems if the disk is XCD.

This is one of the reason im really really waiting a first error tolerant XCD backup creator/filter to be realeased, with 99min disks it allows u to have additional 120MBs of valuable space to play with. with 990Megs u could really make high quality 1CD rips from 90% of movies.

[kilg0r3]

hm, the amount of data devoted to error correction on a mode1 cd should increase with the amount of 'normal' data stored on the cd. so that

700MB CD-R -> 800MB XCD
800MB CD-R -> ca. 914MB XCD
870MB CD-R -> ca. 994MB XCD
900MB CD-R -> ca. 1024MB XCD


o.k., now tell me that i am wrong and why ... :)


[SEARCH TERMS] Mode2, Mode 2, capacity, size [/SEARCH TERMS]

[vinouz]

it's approximative
put some 2356/2048 factor
it gives :
700->805
800->920
870->1000
900->1035
But you have to remove size to this, dedicated to lead in and lead out.

Anyways I'm not at all in the details of XCD specs, so I may be incorrect.

[DeXT]

Well it's not 2352 vs 2048 but 2324 vs 2048 (Mode2 vs Mode1). 2352 is the total sector size, but we are referring to the user data area only. The remaining space up to 2352 is being used for header/subheader/edc/ecc.

Also take in mind that 90 min discs can hold 790 MB (90*60*75 = 790 MB; 800 MB would take 91 min). The same for 99 min discs.

So to make a fast calculation:

80 min: 700 * 2324/2048 = 794 MB
90 min: 790 * 2324/2048 = 907 MB
99 min: 870 * 2324/2048 = 987 MB

However, remember that a Mode2 "Bridge" type CD (such as VCD/SVCD/XCD) takes some space the first ISO track and the pregap of the Mode2 track, which sums about 1 MB (450 sectors), so you should substract it from the raw size to get the real available space. Mode1 discs do not require this Bridge track.

Finally the 80 min CD is a special case because the total CD size differs for each brand, being the "true" 80 min about 703 MB (on Mode2 this gives us 796 MB to play with).

The next mode2cdmaker release will contain a single track mode which removes the need for a separate bridge track, and also makes it suitable for a ton of small Mode2 files such as MP3s (it currently takes extra 300 Kb for each one due to the pregaps).

[Didée]

Would you please stop talking about this ...

... I thought I got it, but every time this topic comes up, it seems I´m doing it all wrong ;)

:D

My typical case:

- Only one file (*.ogm.dat) is burned
- 79min disk - Nero reports 702MB/79min+XYsecs as available
- created OGM is 786 MB (only few times +/- 1MB)
- after burning, the *.ogm.dat shows 799MB/800MB in explorer
- Specific example: For the burned disk, Nero shows two tracks: one of 3MB/6secs, one of 800MB/79min11secs, and a total capacity of 801MB/79min17secs (my rusty maths says 3MB+800MB=803MB, but who knows..)

-> Am I overburning? Am I wasting space? Or doing it just right?

Still :confused:

[DeXT]

Of course it all depends on how are you counting the bytes each block contains: just the user data (either Mode1 or Mode2) or Raw.

So a file spending 300000 sectors on the CD will show itself as 585 MB as Mode1, 664 MB as Mode2 and 672 MB as Raw. It will take exactly the same space (66:40) in either case.

A file being burned as Mode2 will take 2324 bytes of user data per block. Once burned, the file will appear sightly greater in size due to two facts:

a) Windows shows it in Raw size (i.e. 2352 bytes per block) including the (useless) sector stuff
b) There is a small zero padding at the end of the file to fill the last block

I'm not sure how Nero calculates the space spent by the first track. 6 seconds (2 for pregap and 4 for the track data itself) will take 6*75=450 sectors, i.e. 1 MB in size.

[Beave]

@Didée

I think you are wasting space. For me it works great having the .ogm file < 803 MB. It's a little overburned but works totally fine. If you don't want to overburn make 796 MB movies. The resulting .dat file is much bigger then 800 MB, but it's ok.