XCD: automatic media detection and licensing

[The People's Elbow]

maybe this issue isn't new to you xcd developers, but it is making me headaches right now and it's pretty late for me
I'm using the actual riff-cdxa-filter-test6b and stored my .ogm file in mode2 form2 on a nice 80mins cd-r using mode2cdmakergui10.
If I choose .ogm as file extension, i can't play back the file(s)
If I use DAT instead everything works... any help regarding this?
THX anyway, even if this question has been answered already and I'm too tired now and have to take some sleep, no time for forum searches

greetz, Elbow!

[avih]

you are right. it has been answered. the extension selection is NOT for xcd usage. for 800M (and in the future for xcd) the extension MUST be .dat. simply because the file on the CD is NOT an ogm file, it's different, and has to be stripped first. if you burn with ogm extension, the test6 filter is NOT used, and instead ogg dshow filter is used. but it CAN'T strip the file. so it doesn't play.

buttom line: for mode2 files: ONLY .DAT extension is supported. period. if you choose to use other extension, don't expect it to work. it might work, but we can't promise that. stick to .dat.

avi

[The People's Elbow]

THX for the quick reply and sorry for asking lame old questions
... I'm like a noob in this thread

greetz, Elbow!

[DeXT]

I start thinking seriously in removing this feature from next version as Koepi suggested, because seems everyone is using it the wrong way and even Doom9 made this mistake in his updated guide (I already sent him a fixed guide).

This will surely limit the program's scope, but I can re-enable it once the filter or some app supports it in future (very unlikely though). This is not my usual line since I like letting everyone do whatever they want, but this is giving more headaches than advantages I think.

You can put your oppinion here of course, before I release the next version.

[Kyo]

Kill the *.* Bring us the .Dat

Just my $$2c

[kxy]

Yes, we can call the rename of the extension an "abuse". I think one of the main reasons that some users and release groups do that is because windows has very friendly support towards *.avi. Play all, preview, autoplay, auto add all the files to the play list, vobsub etc. A dirty and quick hack is change those extension to avi, then everything works fine.

For example a couple post back, People's Elbow asked, "If I choose .ogm as file extension, I can't play back the file(s)". I think that might be the cause of the play list implementation in the Wimp. Try it out yourself if you have WinXP and WiMP 8, once your have wimp opened, try to drag some files with extension dat or ogm into it. It won't work. But dragging avi files into WiMP 8 play list works fine. Well this shouldn't be a problem for most of the people who hangs out in doom9. But we are just a small scale, for a lot general users out there it is a nightmare! Shift+click will set the player to recognize the file extension but it won't have the above mentioned features.

In conclusion, the possible work around; well at least I think it might be the best is: looking for a way to make a reg filter for dat and ogm that is equally "friendly" as *.avi.

[avih]

your point is indeed valid. however the mode2 file is NOT ogm or avi or mp3 etc. it HAS to be modified (=stripped) to get the original file. therefore a 'familiar' extension will be decieving.

if you have good suggestion regarding this issue, you're welcome to post them here.

cheers
avi.

[kxy]

Yes, it is confusing. And 'Familiar' extension is deceiving! Right now this quick and dirty way is quite popular, simply it is very easy and "user" friendly. Where most the users out there like Joe blow simply don't care what format their files are in or how they are being made, as long as it works. So an image file that is made with mode2cdmaker with "fake" extension namely avi is supported by all the windows features.

I am trying to understand why a lot of people out there would do such a thing. And to see how easy it is, I did a quick and dirty test, and hey, it works! I popped the cd that I just made with mode2cdmaker with avi extensions. The auto play feature came right up, and I clicked on play. The WimP 8 automatically loads up all the files in the cd, including movie files in the sub-folders. (//OT WOW, Anime people can watch all their episodes within one click!) Easy, huh?

Well I am not sure how to implement this. Did the registry has some kind of special way of treating the avi extension where other extension s does not? Or does this involves direct show implementation? Will look into it....

[Kyo]

I know that this seem like a stupid questions/answers around a simple problem but i don´t like that this end in a similar problem
like the !Stop using .OGM¡.

Another solution:
Change the last letter for a BIG X (I go with avih, it's not an avi not a mp3 not a ogg) like mpX ogX
The problem of couse the more archives more extension more crap in the register but may be a solution....


/Crap English, I know /

[avih]

that is a good suggestion but poses a problem.

but 1st a small explanation. when xcd is working (remember this mode2 cd usage is only a proof of concept, and still not ment for real archiving), the original file name WILL be there, inside the header file. i.e. let's say the media file is called 'TheMatrix.avi', and that after making an XCD image, it will be converted to <name>.dat (the form 2 mode 2 media file), and <name>.xch (for 'XCD header') which is the header and the backup sections for 'TheMatrix.avi', then the xch file DOES contain inside it the original file name of 'TheMatrix.avi'.

it's just that the method for storing files don't have it as the file name. similar to svcd or vcd where the filenames are hardcoded, but with the advantage that xcd DOES hold the original name as well, and svcd doesn't.

we decided on this scheme since it's easier for stand alone players to follow, and makes it more compliant with iso 9660 standard (8.3 naming convention).

on top of that, what will happen if tomorow there's a new formal called abc? i.e. 'TheMatrix.abc' . what will we call the mode2 file then? we need a convention for xcd. remember xcd is a storage system. it does remember the original file name, but it put it inside one of the files, and not as the actual file name.

if you want to read the specifications of xcd, to have a better understanding, please go to http://xcd.sf.net

suggestions are still welcome of course

cheers
avi.

[Wuntvor]

This might be really stupid, in that case, just ignore me..

But couldnt the riff filter be first in the chain always, and if there are no riff headers the data is just passed along? In that case the extensions can be what the file inside really is?

Maybe Im missing something ,I probably am ..

regards
/wuntvor

[int 21h]

Originally posted by avih
it's just that the method for storing files don't have it as the file name. similar to svcd or vcd where the filenames are hardcoded, but with the advantage that xcd DOES hold the original name as well, and svcd doesn't.

I don't think SVCD does because you have the availability of Album name and Volume name to use as the descriptor of your disc.

[kxy]

As far as I can comprehend from what koepi said about his xcd backup, is to take the ogm file and strip the first 65536 bytes from the header and store them to xch. So now if the default were dat, how would his backup work? What I am saying is will it be hard for the filter/program to tell what kind of dat file it is and how the header should be replaced in case of a replacement, either it is ogm, divx, tark, or mcf (in the future)?

Please these are just my suggestions; don't make fun of me if I seem like a clueless noobie.

To my understanding, dshow filters uses the stream content to identify the types. First a filter is selected by a string search and it is stored in the registry. If the filter finds the multiple branches for multiple pin output then it stops with the 1st full filters chain it finds. And if no filter chain could be found using the content, then it tries to match a filter using the file extension. If again no filter chain is found, then it says that it can't find appropriate filters and associate it with a major type(is that why ogm and dat is not so friendly supported like the way avi are supported? I think I mentioned it a few post back....)

So I am thinking maybe a few bytes in the header will help to determine the real type of the file so that way it won't be so extension dependent (so users can rename whatever the heck they want). As long as it is known to the filter, as it's true type, it won't matter. So something like 00 for ogm, 01 divx, etc... Another would be a meta file like the mac for identification purposes.

[avih]

@all
pls read the spec to understand better the format of the media and header file.
in short:

- mode2 form2 file: the WHOLE media file with DAT extension.

- mode2 form1 file: the header file with XCH extension. it contains file information (like original file name and original file size of the mode2 form2 file) and backups of critical sections of the mode2 form2 file.


direct show behaviour: when a file is opened, the registry is searched for strings to match the file CONTENT. a mode 2 form 2 file has such strings. these are the RIFF headers of the file that should be stripped (among others) to get the original file. it does NOT depend on the extension.

so, in 'pure' direct show players, the extension doesn't matter at all. every extension will work ok (you can try by using graphedit, insert the riff/cdxa filter as source and click 'render pin' for the output pin). apperantly not all players are 'pure' direct show, even windows media player uses it's own mechanisms sometimes which are NOT direct show's default mechanisms. players as bsplayer always try to OPEN the file themselves and don't use the filter to strip it. such applications will NOT be able to play the file without using the xcd library (when it's available).

possible problems with DAT extension:
1. it's not 'nice' because you don't know the extension just by 'looking' at the file.
2. some functionality is compromized (i.e. media player doesn't play it automatically or doesn't include it in automatic playlists).

problem with 'variable' extension:
1. it's harder for stand alone players to play the file using an automated mechanism.
2. it's decieving since it's NOT the original file with the original extension. it's a modified file. but the original extension may fool applications (or ppl) that try to open the file directly (without dshow or xcd library), to think that it can be opened normally, while really it can't (as is the case with bsplayer) since it HAS to be stripped(=modified to the original file) first.


imo, only the 2nd problem (of using DAT) is important. but that's only my oppinion.

you should also take into account the general aim for xcd: a complete system, with it's own playlist and menu system. the filter is supplied just for a single file playback, for players that DON'T support xcd, but do use direct show. players that WILL support xcd will show the whole cd content, with playlists, original names, menus etc.

now, next time when u post a solution, pls try to describe the problem you're trying to solve more clearly (even if it's not one of the problems i mentioned).

@Wuntvor:
the cdxa/riff filter IS the 1st in the chain (it's a source filter). it SHOULD be selected automatically if the file is a mode 2 form 2 file. we're NOT going to make it a general source filter for ALL files. it's invoked with every mode 2 file. pls excuse me if i didn't understand your solution. i KNOW i didn't understand what exectly were you trying to solve.

@int 21h:
svcd holds information about a file, but NOT the original file name or extension. but with svcd it's not needed since ALL the media files are MPEG2 files. no need to know the extension. xcd will hold extra information about each file, either in the header or in the media file itself (i.e. mp3 file has information in the id3 tag, inside the media file itself).

@kxy:
i don't understand what problem you're trying to solve. recognizing file and using the filter is ALWAYS working in a pure direct show player. and once the riff/cdxa filter is selected, the rest is working ok with dext's automatic media detection. so it's not a problem. if you were trying to solve another problem, then pls describe the problem and the solution again.

don't get discouraged by me replies keep the suggestions going. and again, reading the latest spec will give you more understanding for the problems and possible solutions.

cheers
avi.

[Wuntvor]

hehe...

Well after reading my post again, I am kind of curios where my mind where myself
No need to try to figure out what i meant, just forget it and pretend it never happend
Keep up the good work!


regards
/wuntvor

[avih]

lol
no problem dude

[DeXT]

Hi there. I finally released Mode CD Maker 1.4, you can get it from the link below. Here is the list with the main changes:

- BIG speedup thanks to new buffering (up to 3 times faster!)
- wildcards support
- subdirectories support for Form2 files too
- new option (-x) to keep Form2 original extension into the filename (as suggested by Nah)
- in TOC and CUE the image name is referenced as relative, to avoid problems (thanks kxy)

I finally chose not to put the "alternate way" of entering subdirectories because I plan to add support for entering full paths as input, and perhaps I'll implement it this way.

@Nah: I finally chose -x option to the keep extension of Form2 files, instead of -n, because I have this reserved for Nero image output. Once you update your GUI just remember to change it, and now I think finally there is no need to include a custom build with your GUI (you can bundle the current release if you wish).

BTW this release is 100% compatible with the current GUIs, they just won't be able to take advantage of the new options until the are updated. They will be able to get the speedup advantage of course.

I made my own tests and here you have the results:

K6-2 450 MHz, 128 MB SDRAM, 30 GB HD (FAT32)

        test:  1st  2nd  3rd  CPU

Windows XP:

no buffering  1:02 0:55 0:54  40%
write only    0:24 0:22 0:21  65%
read & write  0:22 0:22 0:20  80%

Windows 98:

no buffering  0:48 0:51 0:50 100%
write only    0:39 0:34 0:37 100%
read & write  0:29 0:27 0:28 100%

This was made with a 100 MB test clip. "no buffering" is the result with the previous release (1.3). The last one is what you get with this new release. As you can see in XP the speedup is more noticeable, while on Win98 you'll get a 80% speedup approx.

The wildcard support mean that you don't need to add single files to -f and -m option when you work from the command line. An example:

mode2cdmaker -m d:\movies\*.* -d player -f c:\player\*.*

This will add every file in d:\movies as Form2 files in the CD root as well as all files in c:\player inside a "player" subdir on the CD. Unfortunately it won't make a recursive search through subdirectories as there is no nested dirs support in the tool, so just the specified directory level will be added to the CD. I hope changing this soon.

As said above, you can now put Form2 movies inside subdirectories too, for example if you have a set of short clips and want to add to a separate dir:

mode2cdmaker -m movie.avi -d clips -m "d:\movie clips\*.avi"

This will add all the movie clips from the specified path into a "clips" subdir on the CD. Previously it would have added them at root.

Hope you like it.

http://webs.ono.com/de_xt/

DeXT

[Kyo]

@All devs. Keep up the good work!
you're making our lives more easy!

Thanks!

[jurij]

Hey good jobe Dext!!!!!
Does this mean we are close to the release of Koepi's Backup tool????

[The Belgain]

Um....just a little question: with the advent of DVD burners, i was just wondering if they wrote data in the same way (ie either in mode1 or mode2, etc) and if this tool (or a similar one) could increase the capacity of DVD-R disks to over 4.7 GB.

Just a thought.