is XCD buried?

[mustaneekeri]

Can i give up hope of seeing working XCD someday?

[avih]

if you wish.
i won't though...

[mustaneekeri]

Good then i wont either, but
i was under the ipression the XCD team is trying to create something so big, that it's never goin to happen.

[SKD_Tech]

I've never heard of the XCD term what are the expectations if it ever comes out?

[kilg0r3]

for me, it works fine. :)

[Atamido]

Though I haven't had a reason to use it yet, I was under the impression that it worked fine.

[mustaneekeri]

Thers no XCD yet, thers (just) a Mode2 CD maker tool (thanks to Dext).
With Mode2 CD u can use the CDs full capacity to store data (about 800MB on a 700MB disk), but thers no error correction!
XCD should add error correction.
Im just worried that things are dragging along so long that DVD burners and writable media comes so cheap that thers no point to develop XCD.
If it don't come out soon, thers no point to develop XCD, exept perhaps in some form increase writable DVD media capacity! But im no programmer and i don't know if XCD can be impelented to DVD format.

[deXtoRious]

Don't worry, a LOT of people (I for example) don't and won't in near future have a DVD recorder, so XCD is needed.

[kilg0r3]

Originally posted by mustaneekeri
i don't know if XCD can be impelented to DVD format.

That'd be interesting to know indeed.

[deXtoRious]

I'm just a newbie at programming, but I think that although it would require some modifications, similar technology for DVD IS possible. I hope ;)

[DeXT]

Okay, some philosophical question arised about the XCD project. Let's share my point of view.

XCD is a high-level implementation of a VCD-like multimedia storage format aimed at the PC (and perhaps some hardware players). It's based on a low-level format known as Mode2 CD, the same one used for VCD.

Currently there's a partial XCD implementation, basically the Mode2 CD maker tool and a beta backup creator. However, there's no support for reading it back. This may change soon if someone skilled enough put its hands on the filter and finish it.

The rest of the XCD format will remain unimplemented until someone wishes to work at it. I'm not really interested in all this high-level stuff, but that's the magic of open source: anyone can contribute. The specs are here, the code is here, it's just matter of resources to make it real. In any case, it's not essential as the thing "works" just with the Mode2 CD format, and may work better with the backup creator AND reader. I can contribute on the former, and maybe on the latter.

So from my point of view, XCD is alive and working since almost a year from now. It all started here (http://forum.doom9.org/showthread.php?s=&threadid=8317). I did my contribution, as well as avih and others. Now, anyone?

Now the technical stuff:

Originally posted by kilg0r3
That'd be interesting to know indeed.
AFAIK that's not possible with the current DVD-ROM reader implementation around. They only allow reading back the user-data area of every sector, as the CSS codes are stored on a separate section on every sector. To be able to sell DVD-ROM readers, any vendor must avoid direct reading of this information by the end user, as this would make any encryption method completely useless (even DVD Audio). We are currently on the same period as the first CD-ROM readers, which were not able to read RAW sectors. Thus we can't take advantage of the potential extra space. I hope this situation changes someday, but it's unlikely, though.

[Neo Neko]

Originally posted by mustaneekeri
but thers no error correction! XCD should add error correction.

Then just use Mode1. ;) It has exactly what you are looking for IIRC. XCD is a tradeoff of CD error correction and detection sections for more user space.

@Dext
I thought it went back a bit further than that. I remember batting the ideas around with guys before that. Well now that I think about it that was another forum entirely. So I guess that might be the first mention of it on D9. :)

[ChristianHJW]

I apologize out front if this seems to be offtopic for some of you, but please allow me to point out that for us the currently existing XCD tools do exactly what we need, as we will have the extra protection as additional EDC and ECC ( FEC ) elements added to the file itself, so we dont need Mode2CD creator to write any mode2 form1 tracks on the CD for that to backup the track/block header information.

Also the current XCD DShow parser will work fine for us, as we dont expect that the ECC elements can be read in real time on parsing the file, but instead we plan to have an external file repair tool that can be used to repair a damaged matroska file read from CD, so it can be burnt to a new CD again after repair.

Of course, it would be nice to be able to play the damaged/scratched CD with a parser that can correct errors on the fly on playback, so we may think of enhancing our matroska parser for that later instaed of simply skipping the EDC/ECC elements on playback, but its certainly not top priority right now and will need a lot of CPU power so it had to be made configurable in the parser setup, and we dont have any plans to make this now ....

[defeatist]

Also the current XCD DShow parser will work fine for us, as we dont expect that the ECC elements can be read in real time on parsing the file, but instead we plan to have an external file repair tool that can be used to repair a damaged matroska file read from CD, so it can be burnt to a new CD again after repair.


I'm guessing PAR2 fulfills this purpose, yes?

[Koepi]

This PAR stuff often arose, if you use the search function. And the conclusion was always the same: so much overhead that it renders XCD useless.

Koepi

[Animaniac]

Originally posted by DeXT
OkayThis may change soon if someone skilled enough put its hands on the filter and finish it.


Hmm, that sounds like a job for Gabest! :D His CDXA filter has worked wonderfully for me!

[defeatist]

Originally posted by Koepi
This PAR stuff often arose, if you use the search function. And the conclusion was always the same: so much overhead that it renders XCD useless.

Koepi

I meant placing small PAR2 files in the Mode1 area of the CD. I may be wrong but I believe that has nothing to do with overheard. Let me know - I think I must have been unclear.

[bond]

According to Christian the next release of matroska (4th august) will CRC32 EDC support in the main lib!
no eec for now :(

Originally posted by DeXT
This may change soon if someone skilled enough put its hands on the filter and finish it.Originally posted by ChristianHJW
Of course, it would be nice to be able to play the damaged/scratched CD with a parser that can correct errors on the fly on playback, so we may think of enhancing our matroska parser for that later instaed of simply skipping the EDC/ECC elements on playback, but its certainly not top priority right now and will need a lot of CPU power so it had to be made configurable in the parser setup, and we dont have any plans to make this now ....this really sounds like gabest is needed :D

this xcd idea sounds really great to me (especially for 1 cd rips) would be great if gabest could have a look at it...

[darth rosenberg]

Originally posted by kilg0r3
That'd be interesting to know indeed.
DVDs don't even have 'modes', so it it impossibe to make something like 'mode 2' for dvds.

[gabest]

Sorry guys, but I agree with Neo Neko, if you need error protection use 2048 byte sectors with ECC, or just buy a DVD burner and have 4.3x GB space for 2-3 rips per disc.

[bond]

Originally posted by gabest
if you need error protection use 2048 byte sectors with ECCsorry for my dumbness but it dont really get what you mean (in context to xcd), cause as i understand it xcd should allow a trade-off between mode1 ecc and the more user data possible in m2f2 (with no error corection)

->
so what we need for xcd would be a container (perhaps matroska) which includes ecc next to edc, which would allow adding some amount of error-correction to the file (movie) itself and to be still able to put more data onto a disk ("trade-off")
as the matroska devels often stated that they dont have the knowledge to implemet ecc in matroska, i hoped that you, gabest, could help out here a little bit :)

am i right, stupid, totally wrong, a dreamer...

[darth rosenberg]

That does not make much sense. You say that Mode 2 Form 2 does not have correction, but that is wrong.

Mode 2 Form 2 has C1 and C2 correction, meaning that anything up to a E22 error can be corrected. In other words, a scratch up to 2mm large should be corrected. This is also the kind of scratch that can be corrected on an audio cd, without any interpolation or guessing.

If you add *some* more error correction, you lose capacity, but don't gain much more correction.

Mode 2 Form 2 has enough correction if you use good discs and don't scratch them. If you want more error correction, use Mode 1.

Actually, you can make Mode 2 Form 2, but add as much error correction as mode 1 has. Then, you again only have 700 MB only, but can have a 'better' error correction (a damaged sector does not get entirely lost, but only partially, for example) and faster error skip without using rude reading methods.

About implementing ECC in matroska: The maths behind ECC is painful...

[Asmodian]

I am sorry if I am confused here...

Reading posts here a long time I though the plan for XCD (no idea who's plan) was to add much better error correction for the header information and such but not for the actuall data stream(s)?
This would give us a CD which would have to be very damaged to not be able to play (due to lost headers) but which would only need small amounts of damage (relative to a normal m2f1 cd) to get errors in the data stream(s) and would hold nearly 800Mb of useful data. These errors in the data stream would not cause major problems because of error compliant containers and decoders such as ogg or matroska and ffdshow.

Was that ever anyone's plan or am i just confused? Has there been a discovery, or does anyone know anything which makes this very hard (impossible :scared: ) to realize?

[darth rosenberg]

It would be possible to add a lot of error correction to essential parts, and leave the actual movie as it is, but no one has done that so far...

[ChristianHJW]

Originally posted by darth rosenberg About implementing ECC in matroska: The maths behind ECC is painful...

Yes, thats true .... the beauty about this in this respect, if we choose the used FEC algo wisely, we could maybe be able to get a pretty good gain/size relationship to preserve the matroska file/track/cluster/block headers, hopefully even better than simply saving them separately as a mode 2 form 1 track ( the original plan for matroska on XCD ).

Frank Klemm, the MPC musepack audio compression developer, had first ideas about a modified Solomon-Reed algo that could be used, but you need a coder like Frank with some very good X86 ASM knowledge to make it fast enough to help correcting errors during playback, else you had to use offline repair tools to correct the damaged parts of a file, before you can actually play it ( time factor is no big problem then anymore ). Unfortunately, Frank seems to be away for some time now ... :( ...

Anybody else volunteering ? Any good FEC algo was a fine start, even with unoptimized code, as that could be done much later also ....