extracting files from XCD via a dshow muxer?

[bond]

i thought about this as i recently read the following in the readme about the dat2file tool bundled with mode2 cd maker:
Beware that if the source file was not an exact multiple of 2324, there will be some padding zeroes at the end of the file. This might prevent it of being played properly.now of course i dont really like the idea of not being able to get exactly the same file out of a XCD as it was used as input

now my question: isnt it possible to "extract" any media file from a XCD via a dshow graph (using a muxer filter) and get a new media file without "padding zeroes" at the end?
are there any other tools which dont add these zeroes during extraction? or which are able to remove them?

[avih]

Originally posted by bond
i thought about this as i recently read the following in the readme about the dat2file tool bundled with mode2 cd maker:
now of course i dont really like the idea of not being able to get exactly the same file out of a XCD as it was used as input

now my question: isnt it possible to "extract" any media file from a XCD via a dshow graph (using a muxer filter) and get a new media file without "padding zeroes" at the end?
are there any other tools which dont add these zeroes during extraction? or which are able to remove them?

strictly, it cannot be done. the very nature of the mode2form2 storage is that it's sector based. there's no indication for the original size of the file anywhere.

of course it MAY be bypassed using various methods. i.e. removing trailling '0' or adding the size of the file at the end of it (and make sure it fits in if the original file's size is nearly full sector multiple), etc.

the xcd way was to store this data (the file's size) in the m2f1 file (.xch). and this is not implemented. although it is in the spec.

[bond]

Originally posted by avih
strictly, it cannot be done. the very nature of the mode2form2 storage is that it's sector based. there's no indication for the original size of the file anywhere.hm but the remuxing via dshow would work?

[avih]

it doesn't matter how u do it. the info just isn't there. the only size there is is the one rounded upwards to full sectors. everything else is derived info and not explicit (i.e. get the file size from the container, detect trailling '0's etc).

and at least the 'official' filter (test6b) doesn't do any such stuff. don't know about gabest's, but i'll guess it behaves the same.

i think it's a matter of trial and error. if the rest of the graph doesn't read/write the auxiliary trailling zeros, then it would work. i didn't test it though. (mind you, other implementations of the 'rest of the graph' might change the behaviour).

[bond]

Originally posted by avih
if the rest of the graph doesn't read/write the auxiliary trailling zeros, then it would work.so it would also be possible that the zeroes get passed via dshow?
i thought about remuxing via dshow, as i thought that only the frames will get passed there

[avih]

this all guesswork by me:
that depends on the container's parser i think. if the parser 'knows' when to stop and doesn't pass any auxiliary data then i think dshow will work. it also depends on how u build the graph. i.e. the the test6b filter alone won't do this (it should though when the xcd header/backup file exists, as then the data WILL be there). but if u add to the graph components that 'understand' the file format (essentially the container imho), then they may skip the extra 'junk' when reading. can't tell if they won't pass that part though 'as is'. as i said, just give it a go (ogm->xcd->ogm via dshow) if u get the original file (use a diff program, or at least check for files size), then it _currently_ works.

[bond]

Originally posted by avih
i.e. the the test6b filter alone won't do this (it should though when the xcd header/backup file exists, as then the data WILL be there).hm so if such a xcd header file exist, the current test6b will handle it already?
if yes, can you post an example for such a file? can it be written "by hand"?

[avih]

no it won't. the header/backup parsing is not yet implemented in the filter (although the infrastructure is there). afaik, there's no header/backup file parsing in any xcd reader that i know of.

[avih]

i should add though that koepi DID write a tool to create xcd header/backup files. but since the filter didn't support using them (and it still does not) we thought it might give false sense of 'security' that there are backup files working, while, in fact, nothing uses them, and therefore the scheme was never tested in 'real world' scenarios.

[bond]

hm but at least it wouldnt hurt to include such a file on a xcd, maybe in the future a tool will make use of it...

[avih]

well, that's EXACTLY the issue. if it cannot be tested, i'm all against it, as it WILL give false sense of security. but as u know, all the sources and specs are out there, so anyone else may have a go.