XCD: automatic media detection and licensing

[avih]

1. de_xt has managed to add automatic media type detection. so now there's only a single filter, which should work with ANY media type that's compatible with windows media players. it was tested to work with avi, mp3 and ogg files. (and it DOESN'T read the whole file to memory, it was tested by people with 800M files right of the cd, and worked fine).

this is probably the last release of this filter before we start implementing the error correction facilities (unless people find some serious bugs, in which case, we'll try to fix them).

again, it's only for testing, do not start using this format for REAL archiving of your clips. please also read the readme.txt file that's attached to this distribution. (as usual, it might take some time before the attachment is approved by a moderator)

2. XCD spec is advancing nicely. atm, XCD has 2 targers:

a. offer reduced error correction (compared to normal CDs) such
that more space of the cd will be used for actual data.
b. be used as a multimedia cd container (i.e. like SVCD) to
be used by both stand alone players and computer players.
it will have playlist and menus support.

this brings up another issue.
we don't intent to make money from XCD. we do however want to keep all the sources and spec open and publicly available, and we want this format to be used by commercial applications and players. and that brings the licensing issue.

some ppl told me that GPL licence might prevent it's adoption in commercial applications. can anyone pls shed some light on this issue for us??

we need:
a lisence that enables commercial applications to use this format, while keeping the sources and spec open. but we don't want any company claiming ownership on XCD in the future. any suggestions??

thanx
avi

[ChristianHJW]

Thread locked by coincidence ? Reopenend it now ...

Reply :

Go for L-GPL license, like MCF is doing. It will allow other authors ( and even companies ) to use your source code even for non-GPL applications, but you have and keep all the rights on your specs and code.

[avih]

i see the file has been downloaded many times. can we consider 'no feedback = good feedback'? :)

the only changed code from the previous filter is the media detection stuff. the parsing, memory usage etc remains the same.

can u approve it's still working for ogg/mp3/avi? (did u also try new media types like asf/wmv/etc?)

thanx again
avi.

2 hours later, another 50 downloads, still no feedbacks? ;)

[ph2t]

Well,

I used the "test4" version, just before the updated media parsing was added and I achieved the following with total success.

1) Created OGM using divx4 .avi and .ogg Vorbis soundtrack with OggMux.

2) Converted the .ogm to a bin file using mode2cdmaker-b11.

3) Burnt CD using Nero, Mode2.

4) Ran the "register AVI Media" bat from "test4" zip.

5) Loaded the avseq01.dat from cd into Media Player 6.4.

6) Beautifull!

Ph2t.

[AlwSN5]

I made an image of a wmv file using the mode2cdmaker and then mounted the image using Daemon tools 3.02 and it wouldn't play. It says it is unable to create the filters for the file. On my hard drive the file plays without error. I also made images using an ogm file and a standard mpeg and both played sucessfully.

Regards,
AlwSN

[spyder]

I now have all types i use(mp3, ogg, avi, mpg) working flawlessly except ocassionally a seeking error in ogg(loses audio). I had to delete all the keys in the registry which had the GUID listed in the regfix in the other thread(i made a backup first). Then all files would play. Don't try what I did unless you know what you are doing. Maybe someone will create a Win 98 compatible reg file to fix this. HINT, HINT. I have no experience with registry scripting.

I have now tried WMA, MPEG(VBR), and Quicktime(Old verison). All files work except the WMA. It says it can't create the filters to render it.

[wing1]

I used test4 with daemon tools on AVI file, and it works fine. Today I saw that test5 became available, so I download it and attempt the test. Unregistered test4 filter for AVI, and delete all test4 files from putter. Unzipped test5 and registered the filter. Create mcf_image.bin with mode2cdmaker using the same AVI file and mount the bin with daemon tools as before with test4. The result is excellent playback and forward/backward/pause/stop are working fine as well. I have not attempt to write the whole thing to CDR and test it yet. Will try that sometime tomorrow if i have a chance. BTW, are you guys have plan on making the mode2cdmaker into win32 GUI? So far this project is doing great.

works with wmp6.4/BSplayer/zoomplayer: All are using ffdshow filter.

bin files are created from 675Mb, 800Mb, and 915Mb AVI(xvid)+MP3.

[avih]

ok gus, thanx for the feedback. great to hear that it's mostly working well :).

i'll summarize the status so far:

the filter:
-----------
- working players: zoom player, bsplayer, powerdivx (aka Core Media Player) V4 beta, wmp6.4, wmp 8.
- it has been found to work with qt/avi/mp3/ogg/MPEG(?)
- it doesn't work with wmv/wma ("can't find filters")
- there's some 'regfix' that helps win98(SE?) users, and seems to solve few problems.

the mode2cdcreator:
-------------------
uses 'fixed' cd label ("mcf-cd")


@spyder, can u point me specifically to this 'regfix'?? i tried looking through this and the previous threads, and couldn't find it.

todo (for test5, if we have time, otherwise for XCD):

1. find why doesn't it play with wma/wmv (do we really WANT to support m$ files??? )
2. add this registry fix to the installation 'script', such that it's working with win98.
3. modify the cd label.

some notes:

mode2cdcreator, and mcfcdcreator are identical, it's just that dext was initially thinking he's working on a specific (mcf) tool, but then found out his work is completely general, so he changed the name.

a gui front end will probably pop up sometime (as well as an XCD calculator, playlist creator, menue creator etc), however, it's a low priority atm (priorities can change though ;) )

if anyone WAS having problems, and managed to fix them, pls share this info with others.


thanx again ppl :)

avi

[Gawen]

You need:
"a lisence that enables commercial applications to use this format, while keeping the sources and spec open. but we don't want any company claiming ownership on XCD in the future. any suggestions??"

I was following the M$ CIFS as "shared source" versus samba development discussion and this is what i learned from it:

M$ uses a lot of open source software in their NT Stuff (NT/2K/XP) but no GPL or LGPL stuff because it would force them to publish the sources of derived works. Taking a look on their IP Stack shows it is based on BSD stuff derived from sources published under the "BSD public license". The BSD public license allows companies to take the sources and build binary only software from it. I am not very familiar with it, so politically it could be useful to enter a paragraph that says if someone uses XCD, they have to credit you in their legal statement and include the XCD license together with a link to the sources in their dists(, so others [competitors] can find it and use it to). This could make it spread faster.

[avih]

@Gawen:
thx, that sound great. we'll investigate this license.

avi

[Gawen]

Btw.: Is it possible to include autostart files on a XCD? I am actually playing around with a mini linux distro consisting of a linux kernel boot image and mplayer autoplaying a video to a vesa frame buffer. This would make autobooting/playing XCDs possible. It will use MPEG-4/7 XML code to determine the media file name and metadata (for menue display later.) But this would need mixed mode, wouldnt it?

[Koelsch]

i also tried OGG/AVI with Test5 Filters in Deamon Tools and it worked with no errors.

i think the main problem with WMV/ASF is, the these files uses the
WM ASF Reader instead of Files Source(Async).This reader is also the splitter.The only solution for this would be, to write a Filter which is able to split the Streams which came from File Source(Async).
i don´t think it´s usefull to do this .. M$ should release a filter which is able to do that.


Regards
Koelsch

[avih]

Gawen:
the initial spec (yet unpulished publicly) already have support for arbitraty binary files for usage with computers (like filters/players/etc).

we didn't think on boot sector yet (or whatever stuff that should make it bootable).

we did think (though not on the spec yet) of a single file at the root dir, that by executing it, the associated compatible player will be launched and play the cd content (with menus, playlists, etc). the spec also has draft support for multiple cd content (like movie splitted over x cds)

we're still working on the spec.
would you like to join? (any contribution is welcome)

just PM me if u do, and i'll update u further.

cheers
avi

[avih]

Originally posted by Koelsch
i also tried OGG/AVI with Test5 Filters in Deamon Tools and it worked with no errors.

i think the main problem with WMV/ASF is, the these files uses the
WM ASF Reader instead of Files Source(Async).This reader is also the splitter.The only solution for this would be, to write a Filter which is able to split the Streams which came from File Source(Async).
i don´t think it´s usefull to do this .. M$ should release a filter which is able to do that.


Regards
Koelsch

thx for the info.
i guess that means no support for m$ media formats atm then, due to lack of appropriate filters provided with win32 OSs. too bad for M$ ;)

however, independant 'parsers' of asf/wmv/(maybe also real media) may be able to handle such streams (i don't know about such parsers/decoders, but they could exist). especially on non M$ platforms.

avi

[Gawen]

@avih
Of cause, will be a pleasure to me.

[avih]

check your PM Gawen.

[avih]

@Koelsch:
i gave it another (short) thought (about foramts that use propriatry/compound source filters).

it could be possible to play such files if the filter (or other module) includes a mini http server, that will read the file from the cd and will expost it from the server. WM source filter (and probably real media as well) can handle URLs, so the player can just play the the file from a 'local' http connection... that could work.

but we do have more important issues atm. anyone wanna volenteer and write one? ;)

avi

[avig70]

I think I can help on that matter !!!

contact me...

[Gawen]

@Koelsch and avih

I think there is not even a server needed, a html file called by windows autostart ini generating a file://|cdrom|/XCD/... URL included in an object tag by JS should be enough.

[avih]

Originally posted by avig70
I think I can help on that matter !!!

contact me on

avi_goldberg@hotmail.com


Avi

great (another AVI?? :) )

avi, we're currently defining the spec (and we still don't know what GUIs we will need). the sourceforge project is still empty, and many ppl are offering help (standards/programming/player support/etc).

i think we should aim to establish sourceforge as the homepage for this project asap, and start to finalize a minimal spec (cd structure and protection method). only then we can start assiging ppl with tasks.

thanx for the offer again. let's keep in touch and hope the minimal spec is finalized soon.

regards
avi

[Koelsch]

Originally posted by Gawen

I think there is not even a server needed, a html file called by windows autostart ini generating a file://|cdrom|/XCD/... URL included in an object tag by JS should be enough.

i think a server is needed to stream the data from Riff/CDXA File Source.

Another way would be (don´t know if this can work), to write a second Filter RIFF/CDXA File Source Streaming with another GUID which is able to Stream Data as Server (with no Output Pin).When this Filter is added to the Graph,it automatically calls Graphbuilder.AddsourceFilter(HTTPFileFromRIFFStreamer).But, i don´t know ,when IMediaSeeking is called, how this will affect the RIFF CDXA FileSource Streamer.This method also maybe break adding Autoload Filters like DVobSub (Autoloading) and some others.
Another thing is, that Dext must implement an option to choose whether the File Source or the File Streamer should be used.

BTW, using a server may also result in creating a temporary file (i´m not sure about that)

What i´ve forgot is, that GraphBuilder.RenderFile(HTTPFileFromRIFFStreamer) may also work, but i´m not sure if this will destroy the RIFF File Streamer.if this works, then there should be no problem with autoloading filters.

Regards
Koelsch

[int 21h]

I modified the command line tool so that you can specify volume name and file output target name... This code is real rough, I don't have a compiler here to test it completely, but I am 99% sure it will work in its current form, only thing I am unsure of is the way I have volume name as a global. So that may need to be changed. Anyways, compile it, and see what happens, but I'm sure at least the file output option is there, also the foundation for adding more options is there, because of the primitive parser I setup.

http://www.missouri.edu/~alb70e/xcd.src.rar

[raistlin2k]

Just a small question, more related to CD-burning than to XCD itself.

Is it possible to burn this XCD in a multisession-CD,
so that I can place my graphedit-files and the mdvd.ini (both required by MicroDVD Player) in a mode1-session and the xcd in a mode2 session?

Is this possible?
Thanks
Raist:confused:

[spyder]

After I thought about it I bet Microsoft has locked the WMV & WMA decoder filters to use only the WM Source filter. That's probably why it will not work with the CDXA filter. Adding the extra zeroes to the end may be what's causing some incompatibilities.

[avih]

Originally posted by raistlin2k
Just a small question, more related to CD-burning than to XCD itself.

Is it possible to burn this XCD in a multisession-CD,
so that I can place my graphedit-files and the mdvd.ini (both required by MicroDVD Player) in a mode1-session and the xcd in a mode2 session?

Is this possible?
Thanks
Raist:confused:

you can try. i don't recommend this however, since your file might not play in the future because there's no error correction. also, the current imaging tool doesn't support the xcd spec, so it won't be compatible with xcd players in the future.

[int 21h]

Originally posted by avih


you can try. i don't recommend this however, since your file might not play in the future because there's no error correction. also, the current imaging tool doesn't support the xcd spec, so it won't be compatible with xcd players in the future.

Technically, there is no complete spec to support. I for one would like to see an initial simpler version of the spec for completeness sake with reserved folders/bytes for future expansion, instead of trying to think of all of these possiblities now. That way work can begin on true imaging tools with error correction to compensate where the container does not.

[DeXT]

@wing1: well the GUI is not one of my priorities since I want first to have a working and full-featured Mode2 CD imaging tool. Anyways the source is open so anyone can build a GUI version out of it.

@Gawen: yes mixed form1/form2 is needed to do what you are aiming for (I want to add support for this in the next release), but for the autoboot feature we need to build a "El Torito" compatible CD. This spec allows to burn a disk image along with the CD image which is loaded by the computer the same way as a boot disk. This feature is exploited by all Windows installation CDs as well as some Linux distros. The problem is, I'll have to find exact info about this format and try to implement it on my tool, so this is not currently a high priority task.

@Koelsch: I agree with you, seems ASF/WMV uses its own File Source filter so a new filter would be needed, and due to the past troubles in the Open Source community related to the ASF file format (see VirtualDub History) definately I'm not going to do this.

About the HTTP server built into the filter, well this is a cool idea but anyways it's a low priority for me, since this is only needed for closed, propietary technologies support such as WMV and RM. But as I said the source is open so anyone can start experimenting with this.

@int 21h: thank you very much for posting your modification. I was thinking in working on this once I am finished with the DSF, but your work will make my life much easier ;)

What I want to be implemented in the next version is exactly the following:

mode2cdmaker -v XCD -e DAT -f autorun.inf -m movie1.avi -o image

-v volume name
-o output image base name (*.bin, *.toc, *.cue)
-f add form1 files
-m add movie files (form2)
-e default extension for form2 (riff/cdxa) files

And in the next one add better support for form1 files so you can add subdirectories and the like. This will help to make a full featured extended CD format for test purposes without the need for a specifically compiled version.

@raistlink2k: I'm not sure about this but you can try do do the following: in CDR-WIN burn the BIN image leaving an open sesion. Then load Nero and try to add a new session. I'm not sure if Nero will be able to recognize it and if it will maintain the XA file flags in the new ISO track.

[avih]

Originally posted by int 21h


Technically, there is no complete spec to support. I for one would like to see an initial simpler version of the spec for completeness sake with reserved folders/bytes for future expansion, instead of trying to think of all of these possiblities now. That way work can begin on true imaging tools with error correction to compensate where the container does not.

that indeed is the target atm.

[int 21h]

Originally posted by DeXT
@wing1: well the GUI is not one of my priorities since I want first to have a working and full-featured Mode2 CD imaging tool. Anyways the source is open so anyone can build a GUI version out of it.

@Gawen: yes mixed form1/form2 is needed to do what you are aiming for (I want to add support for this in the next release), but for the autoboot feature we need to build a "El Torito" compatible CD. This spec allows to burn a disk image along with the CD image which is loaded by the computer the same way as a boot disk. This feature is exploited by all Windows installation CDs as well as some Linux distros. The problem is, I'll have to find exact info about this format and try to implement it on my tool, so this is not currently a high priority task.

@Koelsch: I agree with you, seems ASF/WMV uses its own File Source filter so a new filter would be needed, and due to the past troubles in the Open Source community related to the ASF file format (see VirtualDub History) definately I'm not going to do this.

About the HTTP server built into the filter, well this is a cool idea but anyways it's a low priority for me, since this is only needed for closed, propietary technologies support such as WMV and RM. But as I said the source is open so anyone can start experimenting with this.

@int 21h: thank you very much for posting your modification. I was thinking in working on this once I am finished with the DSF, but your work will make my life much easier ;)

What I want to be implemented in the next version is exactly the following:

mode2cdmaker -v XCD -e DAT -f autorun.inf -m movie1.avi -o image

-v volume name
-o output image base name (*.bin, *.toc, *.cue)
-f add form1 files
-m add movie files (form2)
-e default extension for form2 (riff/cdxa) files

And in the next one add better support for form1 files so you can add subdirectories and the like. This will help to make a full featured extended CD format for test purposes without the need for a specifically compiled version.

@raistlink2k: I'm not sure about this but you can try do do the following: in CDR-WIN burn the BIN image leaving an open sesion. Then load Nero and try to add a new session. I'm not sure if Nero will be able to recognize it and if it will maintain the XA file flags in the new ISO track.

Yea... I was looking at my source some more, and its got issues, the string code I've got in there is all messed up, so don't use too much of that... I think instead of just that quick hack and slash I had earlier, it requires some function additions and modifications, especially for the volume thing. I'm still looking at it now though. The parsing code works fine though :)

[nah]

Hello,
I've developped a GUI in VB to use with the cool tool 'xcd maker' for my own (cause this version is far from good to distribute), but I would like to share it (attached with the post).
I would like to post the prg in my web page but I cannot access the the ftp (www.multimania.fr/zorgzorg).
So I'm waiting for final XCD implementation to begin to burn my avi. Since then, I continue to play with the sources.
Thank you Dext and avih and others for this great tool !

PS : my web page is in french !

[Gawen]

@DeXT
So you said you need info about "El Torito"? I love providing info since i am not a c programmer. (Wished i were.)

The "El Torito" Specs:
http://www.phoenix.com/PlatSS/PDFs/specs-cdrom.pdf

From mkisofs docs:

Switch -b specifies the path and filename of the boot image to be used when making an "El Torito" bootable CD.
The pathname must be relative to the source path specified to mkisofs.
Required to make a bootable CD. The boot image must be exactly the size of either a 1.2, 1.44, or a 2.88 meg floppy.
The specs say it could also emulate a HD.

mkisofs "El Torito" c source:
http://www.openbsd.esec.com.au/ftp/src/gnu/usr.sbin/mkisofs/eltorito.c

cdrecord / mkisofs win32 binaries:
ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/win32/cdrtools-1.11a12-win32-bin.zip

cdrecord / mkisofs homepage:
http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/mkisofs.html

[avih]

Originally posted by nah
Hello,
I've developped a GUI in VB to use with the cool tool 'xcd maker' for my own (cause this version is far from good to distribute), but I would like to share it (attached with the post).
I would like to post the prg in my web page but I cannot access the the ftp (www.multimania.fr/zorgzorg).
So I'm waiting for final XCD implementation to begin to burn my avi. Since then, I continue to play with the sources.
Thank you Dext and avih and others for this great tool !

PS : my web page is in french !

1. i get 404 when tryingh to access this page.

2. the work done so far is COMPLETELY standard and general (standard mode2 form 2 files on standard iso 9660 filesystem). i suggest not reminding anything about XCD yet, since XCD will be an enhancements (in many ways) of the currently available tools. i suggest that the code name for the current work will be "mode 2 form 2 storage and playback system". if you'll mention xcd, people that are not familiar with the subject as much as you are, might be confused. since it's NOT XCD YET.

i also suggest that you'll add as much warnings as you can, both on the web page and your application. (you don't wanna get sued because someone used your tool, and the single copy of his grandma pasha video, which was taken just before she died, will not play anymore, do u?)

you could include this info for example:

"These are 'proof of concept' tools that show that it's possible to store and read on the fly 800M files from 80Mins CDs. (using standard mode 2 form 2 iso 9660 filesystem).

as much as it's a good proof, it still suffers from MAJOR drawbacks:

1. The file might get corrupted very easily, since there's no error correction. it's very likely that your favorite birthday clip will not play next week if you'll burn it using these tools. (yes, even if you use 'protected' containers such as ogg)

2. These tools are not supported by the developers except for testing and bug reports. the developers also stress as much as possible that you should not make REAL archive using these tools.

3. the developers are planning a new system, called XCD, that will try to overcome the problems noted above, and offer even more features (like playlists and menu system). BUT untill XCD is available, there's no 'safe' way to store 800M files on 80Mins CDs.

if you want further info about XCD, check Doom9 forum and the following threads:
<here u put links to this thread and others related to XCD>
"

ok? :)

avi

[nah]

Hi Avih,

Ok, I understand
Sorry for the 404 error, I can't acces myself to the webpage.
Hope the moderator doesnt post my attach file. I will rename the prg and fill many warning as possible.
Thanks

[int 21h]

How is work progressing on a basic implementation of the spec? (i.e. just error correction, general notes, etc.) It's pretty important so that we can implement the correct tools to produce these images, and then do some wider scale beta testing with the tools to uncover any bugs that may not have been considered yet.

[nah]

Hope that noone have downloaded my previous attachment.
The program is now on my web page :
http://membres.lycos.fr/zorgzorg
Hope that XCD become true because I have some 800 Mb movies waiting in my HDD ! :)

[spyder]

I don't know how interesting this is to many of you but I have almost completed a new Java InputStream Class that will read from one of these files seamlessly to the program, just like any other file. I hope to make this an option fro Java Media Players. A question though, these RIFF headers, are they only Windows related or do the files read the same on any other OS with support for Mode-2/Form-2?? I need to know what kind of structure the files would have on Linux for example.

[ChristianHJW]

@Spyder :

milkman_dan ( Jon H., he is dev member of MCF, check http://sourceforge.net/projects/mcf ) and Mark Willberg are both working on Java based programs for MCF and/or Ogg.

Mark can be reached via the powerdivx.com Forums, nick 'mwillberg' . If i remember correctly he was working on a java based MCF parser. milkman_dan is coding a MCF muxing/editing tool based on java called '-gemma', so both might be very interested in your code. I Guess milkman is registered here also, not sure ....

[spyder]

Thanks Christian, I would really like to be a part of this project if they need help. Unfortuanately I don't have time to cantact anyone today and my time will be limited for the next 2 weeks until school is out. After that though I will have plenty time and I actually was thinking about making an Ogg Muxer and Demuxer and maybe MCF later on. I will talk to them as soon as I get a chance or they can contact me at spyder482@yahoo.com If they see this.

[DeXT]

@Gawen: thanks a lot for the info, I found it very interesting and I think I can implement boot CD support in a future version. BTW it's fully backward compatible so it does not cause any VCD compatibility issue, the same as Joliet (both make use of additional Volume Descriptor entries).

@int 21h: there is no base implementation yet, the XCD specs are still in design phase. Of course any help on this subject is welcomed! ;)

@nah: thank you very much for your contrib, it's a simple but cool GUI. I couldn't make it work (it says no destination path is defined and I cannot enter one) but it's nice :)

@spyder: I think this is an extremely interesting contribution, it can help to add support for RIFF/CDXA files in Java apps out-of-the-box. I think it would be desirable to put this into the XCD sourceforge CVS repository (I'm going to put my tools here too).

[Gawen]

@DeXT

Your welcome. :D I am far from being worlds greatest hacker, but i am a usable supporter. I have a multi controller cd automounting static linux kernel binary ready to run and a static multiformat multicodec version of mplayer. The kernel will fit on a 2.88 floppy image, together with some support tools, but the player binary is 5 MB in size. What would you prefer, creating a larger hd emu image or putting the player on the ISO 1 track of an XCD in a dir like bin for instance? Placing the player in XCD-Root:/BIN would be more flexible, because the content could then be made autoplayable in linux without needing an additional player or booting. Mplayer supports Div3/4/X/MPEG-X muxed with PCM/AC3/MP2/MP3/AAC in MPEG-Streams, AVI, OGG, MOV, MP4... (plus numberless formats and codecs i forgot because of their lesser importance for me).

I need to know for doing some tests. Will simulate a future version of XCD by unpacking and repacking of the XCD tracks with mkisofs. By the way: XCD tracks are mountable with cdfs under linux. On success i will post a link to an autoboot/autoplay iso based on XCD.

[Kb_cruncher]

well,i have burned a ogm file without success.
first i registered the filter successfully,then created the bin file successfully,burned with cdrwin(default settings)successfully.
Windows xp could not read the cd :-(

file is divx5 not xvid.is this my problem?

[DeXT]

@Gawen: I think I prefer the /BIN method because in any case you have to mount the CD, and HD images are harder to create. It would be great if it would fit in a 1.44 MB image because this way everybody can do their tests much more easily. This comment about Linux being able to mount XCD tracks (I assume you can read the M2F2 tracks?) is pretty interesting. It would help a lot if you can confirm this and tell how Linux access its contents (ie. in RAW mode like Windows or just the user data).

@Kb_cruncher: no the video CODEC has nothing to do with your problems. This can be either a burning issue or a CD reading issue. I'd bet the former, i.e. the CD has not been burned correctly. This is not your fault but mostly your burner/software combination. You could test this by burning a VideoCD with CDR-WIN, it will probably fail.

I've received reports from people having such problems, both CDR-WIN and Nero being not able to burn Mode2 images with crertain burners. I'd suggest the following: use a recent Nero version (Nero 5.5.5.2 and previous versions are known to have troubles with CUE/BIN images) and/or try the single track burning method:

1. load Nero
2. select File/Burn Image
3. load the BIN file (NOT CUE!)
4. select Mode 2
5. burn!

This has been reported to work even on problematic burners, where no other method have been successful.

BTW I will add NRG (Nero) image output support in a future version, hope this will contribute to eliminate potential Nero issues.

[spyder]

@DeXT- I will let you all know once it is complete. I have basic functionality working but I'm filling in all the other InputStream methods to work properly for skipping bytes and so forth. I am writing this to work with older JDKs not using the new JDK 1.4 extensions so it should work with most apps, old and new. After I have it complete I will post it on my site and then see about the XCD CVS. I will also include a modified MP3 player written in Java to play from CDXA.

Also, I use Nero v5.5.7.2 ando I have no problem burning a CUE/BIN combination. I just pick File->Burn image.. and select the CUE file.

[spyder]

@Gawen- Does this Linux media player you have need an X windowing system or does it work without it? If it requires X that will tak a cnsiderable amount of space.

[Koepi]

he already wrote that he uses the framebuffer device...

[Gawen]

@DeXT
@Gawen: I think I prefer the /BIN method because in any case you have to mount the CD, and HD images are harder to create. It would be great if it would fit in a 1.44 MB image because this way everybody can do their tests much more easily. This comment about Linux being able to mount XCD tracks (I assume you can read the M2F2 tracks?) is pretty interesting. It would help a lot if you can confirm this and tell how Linux access its contents (ie. in RAW mode like Windows or just the user data).
I am actually evaluating. 3 choices:

- Patching vcdfs to kernel 2.4.18
- Using cdfs, a somehow enhanced alternative to vcdfs
- patching mplayers vcd code to accept XCD

Cdfs means building a kernel module or compile a static kernel, patches ... you know i am not a c crack. My actual strategy is mount the cd with cdfs, mount the XCD track to a loop device (thats the way cdfs works), read the RIFF header and generate a link to the data file named from RIFF header content (later multiple links to multiple files plus a playlist for mplayer), then start mplayer play that link. I am NOT ready with it yet.

2.88 floppy format is no problem, it only means you will get a 2.88 linux boot floppy image file from me. It does not need to be written to a real floppy drive, its the image "El Torito" bootloader uses as a virtual floppy drive to boot the cd after having read it from a cd track. But it needs to be a value bioses can be spoofed with, so max is 2.88 MB. I hope it will be possible to use mkisofs for win32 to create a cd with the linux autoboot files on windows maschines.

Give me a day or two more for a prototype. :cool:

[Gawen]

@spyder

Ever heard of embedded linux for handhelds like the new Sharp? ;)

Koepi is right. I could even build a complete distro for it, but that would take too much time to boot and would take a lot of files and storage. Too complicated. I decided to use the one and only graphics card independend device, the VESA interface, supported by the linux VESA framebuffer device. It uses fixed grafics card bios addresses that are standartized and actual cards are fast enough for realtime video display. For more info read the FAQs and forum posts on http://www.mplayerhq.hu . The whole thing will consist of 4 files for the windows user: A linux boot image, the precompiled player binary, mkisofs.exe and a batch to add the stuff to an existing XCD. I am evaluating on a 100 MHz FSB i810 board with VIA Ezra 650 MHz CPU, so hardware requirements should be modest enough. Whish me luck, i have a running kernel, a working player and now i am in the stage of implementing the framework around that. Space consumtion will be < 10 MB (actually 2.88 MB for the boot image and 5.5 MB for the player). And in my opinion it should only be an allowed option for a XCD, no must. Imagine simply booting from a CD and watching a film, sharing it with others and beeing shure, they can watch it to, they will never again come back to you and say "But my player said he doesnt understand it!". No need to explain ogg, mp4, mov, avi, divx, xvid, mpeg-4, mp4v3 ...

Real good things should be simple. I try to keep this thing simple.

[avih]

gawen: 2 things:
1. the user must be certain the mplayer version and codecs support his/her container/codecs. (we should think of a way he can know an answer for sure)

2. take into account the fact that after the boot sequence, the player shouldn't acces the disc at all: the playback could skip or jitter, and the user may insert a new cd for a clip/content spread over more than 1 cd.

cheers
avi.

[DeXT]

I decided to post the current mode2cdmaker build (named 1.2pre, "preview") because I'm going to add Form1 support and this will take a good amount of work, since somewhat profound changes are needed for this (currently the ISO track structure is fixed).

No exciting new features, just the stuff I talked about some days ago, i.e. the ability to put wour own volume name, M2F2 file extension and output image name. I did it mostly to get rid of all the remaining MCF-CD stuff. BTW the command line stuff is courtesy of Nic (sorry int 21h I finally used his stuff but anyways I've put you in the credits since you deserve it too).

BTW the default volume name is now "MODE2CD", I know it's a bit ugly but avih preferred not to put "XCD" yet.

The new syntax is as follows:

mode2cdmaker [-m] movie1.avi [-o image -v MODE2CD -e DAT]

-v volume name
-o output image base name (*.bin, *.toc, *.cue)
-m add movie (form 2) files (default)
-e default extension for form2 files

I finally chose to make the "-m" option the default one so you can continue using the old syntax (i.e. no options at all).

I will work on the Form1 stuff now and investigate the potential problems with 90/99 min stuff.

BTW I'm putting it here because my server is down (again), damn I need a new server. Hope you find it useful.

[Gawen]

Originally posted by avih
gawen: 2 things:
1. the user must be certain the mplayer version and codecs support his/her container/codecs. (we should think of a way he can know an answer for sure)

2. take into account the fact that after the boot sequence, the player shouldn't acces the disc at all: the playback could skip or jitter, and the user may insert a new cd for a clip/content spread over more than 1 cd.


Hi Avi,

1.is not a problem, mplayer generates a codec list at compile time for its codecs.conf.

2. i have that already in mind an will care about after completing a 1 CD prototype. I dont think it will cost to much work, cause the player with its virtual floppy device is still in memory after the first cds end, so all there ist to do is prompting for shutdown or continuing and if cont. unmounting the cd , prompting for the next one, deleting the old links, mounting the new cd, creating new links and start the player again. And so on. This is a job that can be done with a shell script. No need to start a IDE for it. Wait a little for the first prototype. I will post a loud hurray message when the first film is running on the tv out of the Radeon in my main workstation. Later on it will maybe also support IR remote control support, but i will have to get my soldering iron hot for that. :D

Edit: P.S.: XviD build 31.03. works smoothly and for compatibility testing i actually use the DX5 xXx trailer avi from dxn/sony. Actual enough? Or is there a better XviD build on the same stability and speed level i should test?

Edit2: "the player shouldn't acces the disc at all" sounds a little like virgin birth, doesnt it? ;) I tought of doing something like "xcdcat input.avi | mplayer -" if i get trouble with the first RIFF header, xcdcat would cut it and pipe the "rest" of the file to the player. A pipe gives you 4 MB buffer automatically. Should be enough if you dont try using it jogging with your notebook in heavy area. And keep in mind: Its Linux! (No $ sign in it, pure processing power.)