Mode2cdmaker? how come it cant add 000's to extra file for 2324 compliancy??

[\AX]

I dont know where this ? should go...but i just read the readme taht comes with the app...it say's it adds 000's to the end of the mode2 form source files...and there is nothing anybody can do about it. This as stated can lead to playback problems possibly.

Ok, but how come it cant add in a extra file to make up for the difference??? This might be because it does this will EACH file vs all files combined right??? If this is true this suggestion is out the door.

How come the app couldnt getsize() or whatever of the total files to be burned and use modulus to create a dummy file.???
Like something like the below...

foo = imageSize % 2324
if foo != 0 then
{
code here to output a dummy file of the remainding bytes with or
without overhead of 300KB (or whatever overhead/calculations are
needed.
}

im not sure still if it has to be for EACH file and not the whole lot. If it has to be for each file is there any way to trick the image into thinking its one file instead of movie.avi and dummydat.dat ???

anybody know what i mean?

[avih]

the spec is here: http://xcd.sf.net
this 'dummy' file is called the xcd header file. it's not yet implemented though.

[\AX]

Good to know its being implemented. Is it close to beta yet with this feature?

I read that page, it said the last update was May, 2002? I think the most interesting part to me is the part that describes one of its goals is to be played by standalone players...is this even possible? Would standalone units have to have the decoder built in for this special format?

It also mentions something about error handling, like for streaming media. Does .OGM or any of the listed formats on that page support this (besides mpeg2)?

Great work. Im just hesitant to try it out yet due to im not sure how the decoding/filter works and if it is in a good stage to say its "stable".

Something else not listed on that page i thought of from school to here is that could it be possible to just trunacate the last 2323 bytes off the end in the image file. Like if you had INTENTIONALLY put those bytes there for this purpose. Would that be easier than the "XCD header file" ??

[DeXT]

Seems you are a bit confused about the way the padding is being done, so I'll explain it a bit.

The reason for the zero-padding at the end of every Form2 file is due to the fact that Form2-filesizes have to be specified in terms of blocks, and not just plain bytes like in Form1 files. The file length that Windows shows you for Form2 files in not the one stored in the CD. This was due to the need to be backwards compatible with older ISO 9660 parsers, which do not support the XA extensions.

This only affects Form2 files and not Form1 ones. Every Form2 file has its filesize raised a bit up to the next 2324-byte boundary. However, this padding has no side effects on most file formats: we tested AVI, OGM, MP3, MP4, RM etc with no problems at all. Yet have to see a format having trouble with this.

Anyways, when XCH support is implemented, this problem will definitely dissappear, as there will be a way to know the exact original filesize.