XCD: automatic media detection and licensing

[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.

[nah]

Hi,

Thank's DeXT for keeping the extension (-x).
Directory for Form2 files is OK.
A bug in the cue sheet : error from Deamon 3.11 which only can handle sequantial track number :
-----------------
FILE "image.bin" BINARY
TRACK 01 MODE2/2352
INDEX 01 00:00:00
TRACK 02 MODE2/2352
INDEX 01 00:06:02
TRACK 07 MODE2/2352
INDEX 01 01:43:50
TRACK 08 MODE2/2352
INDEX 01 01:53:68
-----------------

not tested wildcards feature

I'm updating my GUI

[nah]

Ok,

I've updated my GUI to use with Mode2CDMaker 1.4.
http://membres.lycos.fr/zorgzorg/Luigi/prg/update.zip

What is the status of Koepi's backup creator ? :(

[Koepi]

Hi nah,

just send me a PM with your eMail-address and I'll send you the sources. You can take out the ogg stuff directly as it is unlikely to change... so at least with *.ogm we can offer some "error correction reduncy"...

Regards,
Koepi

[DeXT]

Hi there. sorry for the delay, I've been away for a couple of days...

@Nah: thank you so much for pointing to this bug, a stupid one I know, sorry. Hopefully CDR-WIN was not affected because it does not trust the track numbering in CUE files. I just uploaded a new 1.4.1 release which fixes this (get it from the link below).

@jurij: no idea sorry, unfortunately this is not on my hands right now.

@The Belgain: I lack many informations about how DVDs are phisically stored and if they could use the Mode2 Form2 mode, but I guess that since it's a format derived from the CD-ROM perhaps it's possible to take advantage of this. Anyone with deeper knowledge about DVD burning would be welcomed...

Thank you for your support.

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

DeXT

[Koepi]

Hm, DVD uses UDF as filesystem and as such it is _impossible_ to do any fancy stuff with it. You simply would break any compatibility - you won't be able to access a DVD if you mess around with that...

Just a thought - we managed that with XCD already, why shouldn't a new DSF be able to read that again.... but I'd wait until DVD-R/RW are mainstream enough so that we could test around without problems...


Regards,
Koepi

[neodivx]

I have also look your source, great greatjob. I have made a project in builder if you want to:

there is the link:

Full install: http://www.neodivx.org/file/avicompressor.zip
This is the full install with the filter and so one.

The source: http://www.neodivx.org/file/avicompressor_sc.exe

Hope this can move the project.

Neodivx

[kagoru]

Thanks DeXT! I finally got it! That's the catch then for having 800 instead of 700 MB.

[mustaneekeri]

Just asking, since things in my opinion have been little quiet in XCD front lately, how close are we seeing the "official" XCDfilter release and a tool to create one?

[scorchED]

i am using the latest OGM and XCD files. so i am burning up to 920MB on a 90min cd-r on my plextor 16/10/40. as burning software i am using Nero 5.582.
the reult work very fine on my cd-drives, but it doesn't work on my NEC DV-5700 and Toshiba SD-M1612. i can see the movie file (ie. movie.ogm.dat) but can't open it :(
the same on a 80min cd-r is working great on my dvd-drives.
Could anyone of you tell me why the movies are working on my cd-drives but not on my dvd-drives?

[Belgabor]

iirc dvd drives seem to have problems more often with XCDs that cd drives. Other point, are you sure they read 90 min cdrs at all? Not all drives do.

Cheers
Belgabor

[MaTTeR]

@scorchED

Make sure all your drives have the latest firmware flashed. Also, many drives will not support CDs over 80mins in length. DVD drives seem to very problematic in this respect in my experience.

If you can see the file then you should definitely be able to use dat2file in order to copy the file locally and then view it properly.

[mustaneekeri]

If u want to plan ahead u can buy a Lite-On LTR-163 DVD drive, its cheap and capable of reading CD-Rs upto 99:59mins.
My "XCD" rip with 990MB .ogm files play just fine with it, straight from the CD.

[Defiler]

Originally posted by mustaneekeri
If u want to plan ahead u can buy a Lite-On LTR-163 DVD drive, its cheap and capable of reading CD-Rs upto 99:59mins.
My "XCD" rip with 990MB .ogm files play just fine with it, straight from the CD. I bought a pair of them to keep in my closet, a while back.. Just in case my main unit fails me. The perfect drive, in my opinion. I don't think we'll see its like again.

[stargazer]

Originally posted by Defiler
I bought a pair of them to keep in my closet, a while back.. Just in case my main unit fails me. The perfect drive, in my opinion. I don't think we'll see its like again.

Great drive, only problem was 16x speed limit when reading RWs, but as I can see, they've fix it in last firmware update!

[Emp3r0r]

what is the difference between 163 and 165?

[Emp3r0r]

nevermind, the 165 plays newer DVD-Multi, I just bought a 165 for 39 bucks shipped.

[hazedlife]

Thanks for the info, i had a couple movies that are over 700mb and i wanted to get it off hd.
Thanks again, much appreciated!!