View Full Version : XCD: automatic media detection and licensing
avih
30th April 2002, 18:29
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
30th April 2002, 22:13
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.
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? ;)
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
1st May 2002, 03:51
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
1st May 2002, 04:03
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.
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.
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
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.
@Gawen:
thx, that sound great. we'll investigate this license.
avi
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
1st May 2002, 12:48
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
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
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
@avih
Of cause, will be a pleasure to me.
@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
1st May 2002, 14:01
I think I can help on that matter !!!
contact me...
@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.
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
1st May 2002, 16:07
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
1st May 2002, 17:00
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
1st May 2002, 22:24
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
1st May 2002, 22:32
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.
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
2nd May 2002, 00:00
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.
@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.
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
2nd May 2002, 02:06
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 :)
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 !
@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
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
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
2nd May 2002, 17:24
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.
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
2nd May 2002, 23:50
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
3rd May 2002, 09:23
@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
3rd May 2002, 22:00
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.
@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).
@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
4th May 2002, 16:44
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?
@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
4th May 2002, 17:57
@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
4th May 2002, 18:19
@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.
he already wrote that he uses the framebuffer device...
@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:
@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.
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.
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.
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.)
gawen:
concerning the licenses again.
1. as we all agreed, we're switching the xcd.sf.net account to BSD license (instead of GPL).
2. i did send a support request to sourceforge team already about this issue, but let me post my thoughts here as well:
de_xt tool is based on vcdtools which is GPL, i guess your linux kernel is either GPL or some kind of Debian license. mplayer is GPL mostly (some parts are not GPL).
since we want to include all the tools under a single 'roof' (do we?) how do we license different 'sunprojects' under different licenses? also, the spesification themselves are not code, and i think BSD/GPL/etc doesn't reference them. any idea about what should we do about the specs themselves then?
avi
ps.
'the player shouldn't access the cd' is partially correct. the correct one is NOTHING should access the CD (including the kernel or other applications/scripts/etc).
pps
i've reactivated http://xcd.sf.net
spyder
5th May 2002, 00:16
I have completed the first beta of my XCD/CDXA tools for Java. Currently it includes a java version of dat2file and a InputStream class for reading M2F2 files directly within any java app. I will modify the sources of JavaLayer to use this stream and post it here unless there are licensing issues. I hava attached the ZIP file containing the compiled versions along with the source code.
I would like to put these files in the XCD SourceForge CVS. I guess I would have to be a member of the XCD project. How do I sign up? Until XCD matures a little more(gets error info), I will work on possibly MCF in Java.
spyder:
gimme some time to set up the account correctly. currently only the initial draft is uploaded.
also, since m2f2 is not XCD (it doesn't have error correction), i prefere not calling all the m2f2 work XCD ok?
i'll let u know when the project starts rolling, and add you as a developer.
avi.
spyder
5th May 2002, 00:54
avih:
Thanks. The actual files say nothing of XCD except the Readme says XCD/CDXA I think. I will change it from now on until the XCD spec is finished.
Belongs on what we want. If i interpret our intentions correctly we all want the best possible availability for the format. So we should put the format specs under the best licence we can give without putting it fully into PD. BSD should be good for it.
On the other hand there is software derived from different sources with different licenses. Well, we should use the best we can without violating the will of the others, wich made software components we reused. And this is no problem if we tell this openly. We should "label" the software components with the best licence we can.
And there is no need to do more. We want the industry to adopt the format. If they like it, they can use the format specs for compatibility and for free. Now its their choice either to say:
- "Ok, there are programs we may use, its no problem for us to put our changes under the same licenses too."
- "Ok, but GPL is not acceptable for us, we will order our coders to do a rewrite, thanks for the examples."
- "Ok, but we dont like GPL and have no coders to rewrite, could you do a rewrite for us, we will hire you for that?"
The last point is the only important one, would we have the capabilities to do a rewrite if someone would like to hire us for that? Its the only "service case". Every other usage would be self service and the only thing that could happen is being asked "How can we do this or that?", "Could you have a look on my implementation and certify it?".
The parts i do are just compiles of existing software, an OS, a Player. As long as i dont change the source i only need to give credits on where they can be found. They all are GPLed. Nobody working in the bizz would ask us to do rewrites of them, because anyone would know it takes a little more workforce and time to do a complete OS.
So what about the other parts? What is in where? We need a matrix we can publish. If nobody can have a misunderstanding, we are not in trouble. We just have to be straight, open, helpful, friendly. Thats all. We are giving a concept for free, including a reference implementation. If we can make someone get $ signs in his eyes with it, we will see.
I am working now for 15 years in the bizz (call me grandpa) and there is nothing i see trouble with yet. We can only get in trouble if there are black holes, trapps that other could tap in. If we tell the truth, beginning with the executive summary and ending with the specs and the attached licences and credits, this can become a widely used format very quick.
spyder
5th May 2002, 01:33
I have finished modifying the source for JavaLayer 0.2.0(GPL) to use my CDXA class. It only required that I change two lines, one to import my package and change it from creating a BufferedInputStream to creating a CDXAInputStream.
That's how easy it is to make a Java app read from CDXA now.
To use this read the Readme inside the Jar file or extract the jar file to your classpath and run:
java javazoom.jl.player.jlp [inputFile.dat]
I have attached the compiled version and source in a jar file inside a zip file.
avig70
5th May 2002, 08:07
Hello all
Here is a idea I'm playing around with for some time.
Is it possible to make a bootable CD that once you turn the computer on it contains a programm that makes the computer dedicated to playing the movie on the CD.
You could probebly play movies on much older machines once you don't need to run the windows or the linux kernel along with other things that run in the background.
It will need some kind of minimal kernel to interface specific hardware devices but it will be allot less overhead and dedicateto runing the OS and allot more resources to playing the movie
Avi
AviG,
guess what that BootCD stuff is all about we are writing from?
But thanks for repeating it in some clear, simple words :P
SCNR, :)
best regards,
Koepi
avig70
5th May 2002, 11:50
sorry
avig
@AviG
I am working on that stuff, but dont exspect it to run mpeg-4 files fullscreen on a very old maschine. I use a networkless Kernel 2.4.18 with graphics hardware optimization and multiple ide/scsi disk drivers booting in VESA framebuffer mode and playing than with a statically compiled mplayer. The Kernel is not the limit, the player is not the limit, its limited by zooming mpeg-4 films to fullscreen. These operations are very cpu intensive, so the lower limit at my testfield is actually a coppermine celeron at 800 Mhz. I will try to optimize this, but mpeg decoding has its limits. Thats why STB manufacturers use dedicated high speed DSPs for this job. Another limit is memory bandwidth for the pictures size. 100Mhz buses get filled up very quick when copying the decoded frames to the graphics port at sizes > 640*480. My target is to get it running on a 100$ VIA Eden mainboard (mini size with VIA CIII CPU soldered on board).
avig70
5th May 2002, 16:44
Hello again
I have a P-III 550Mhz and it runs the MPEG4 films full screen with no problem on 800X600X32 so I'm not quite shure what you meen.
I've also ran it on P-III 450Mhz and it had a little problem so I guess thats as low as you can go as far as MHz are concerned.
And another thing why is the memory involved ?? arne't you supposed to write directly to the video adaptor ? I probebly didn't understand you.
Avig
@AviG
I am not going to discuss your hardware and my project here with you. If you want to learn about the limitations of memory buses writing raw data to low level badly supported ports, take out your old HP calculator and calculate the limitations of a 100MHz 32 Bit memory bus transfering mixed datastreams in and audio and video datastreams out to sound hardware and the VESA interface. There will be a prototype in the next days and you are invited to optimize it, i will be happy to apply the speed patches you send me.
Again, thanks a lot for your interest.
Gawen
Hm, 100MHz x 32 Bit doesn't sound too bad for me as this makes ~400MB/sec possible (100.000.000 x 4 Bytes).
Uncompressed video would need max (assuming 720x576 resolution) ~30MB/sec at 25fps, ~35MB/sec 30fps (once more assuming we have 24bit color depth which isn't necessarily the case with vesa fb, usually you have 16 bit color depth there).
Even if we pull up the resolution to 1024x768x24bit, it would result in ~56.25MB/sec at 25fps respectivly 67.5MB/sec at 30fps.
This doesn't seem to be the bottle neck :)
I just wanted to throw this in, and hell yeah, I know about wait-states and so on ;)
Best regards,
Koepi
avig70
5th May 2002, 20:21
@Gawen
Didn't meen to upset you but...
Let me know where to discuss it and I'll go there.
It just seems like you're kernel might be initializing the CPU registers in the wrong way..
Thats all I wanted to say, and I'll be happy to take a look at the code and learn.
Thanks
Avig
@avig70
gawen is still working. let him play with it, and whe'n he's minimally satisfied, i'm sure he'll post the work. you'll then be able to tweak it as much as u like. just let the man make some progress first ;)
avi
@ los dos avis
You may eat me, when the first prototype is ready! *g* I shouldnt post info about pre proto performance probs.
If it had to perform on only one I/O chipset and cpu, say Intel I81x and PIII, it would be easier, but i need DMA on all major chipsets, with PIO access FPS values tend to 5-10 frames/s. I stopped counting the kernel compiles last night and test on 3 PCs with different PCI/IDE bridges in parallel. Wish me luck!
@koepi
You are great in calculating the ideal case where no postprocessing is neccesary. Of cause, then it works. Divide by 2 for IRQ/WS overhead, add some streams for cd reading, resizing, colorspace conversion ... if done by different program units that communicate via memory bus ... , you run into a realtime performance prob. But do i have to explain this to an XviD team member? :sly:
unplugged
5th May 2002, 22:41
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.
To remember that this kind of binary CD images need the "famous" capability of RAW writing :) by the CD-R/RW writer unit...
Not much time ago there was been a lot of discussions about old and new burners regarding RAW writing support (entire sector... ECC EDC...), remember the first CloneCD launch era!! :D
about M2F2 interest:
Without discrediting XCD intentions and efforts, I have to add some thoughts derived from the M2F2 spuring concept too:
Why do not *also* consider a simpler "slick" version of XCD specifically oriented to host already-known file-systems (firstly CDFS), this to do a strict container based variant?
Describing the binary, simply a primitive layer with very little ID/Info header and a cluster structure with *only* EDC CRC-check embedded.
Just a quite RAW container to mount inside any needed standard filesystem (layer 2). With unique strategy to read problematic sectors by rereading at lower speeds :o, or simply rereading. (using cluster CRC data as triggering mechanism of course).
Just to have no overhead CDs not difficult to implement (small driver mount-engage filesystem routines), to contain media (stream) content that doesn't require high read speeds (no more than 4x-8x, 600-1200Kb/s) and mostly sequential reads.
You could quickly say that burning such kind of CDs is a jump in the dark... :) but mode 2 form 2 CDs are commonly readed differently by CD-ROM units, at lower speeds of course (more accurately), just after fresh insert.
Make a try with PlayStation CDs (M2F2 too) or Philips Video CDs by inserting these on home PC, typically CD-ROM unit rotation speed is identical as for ISO-CDs (40-50x) but if you test effective burst speeds the unit transfer is pretty close to 12x!!!
In most of cases (talking about CD-ROM units) these CDs are readed more carefully.
In fact, by experience make on fly copy of a M2F2 CD is a PAIN!!! :devil:
--------------------------------
http://www.elby.de
check if you have DAO-RAW or at least SAO-RAW.
Right? :rolleyes:
@unplugged:
thanx for the info and ideas.
we already think of read speed control. in fact we're just discussing it few mins ago on irc with matter and dext.
regarding the cd format: we want it as compatible as possible, so we chose the s/vcd paradigm since there are many players that can read such format already (as well as windows and linux). we're always open to new ideas though.
i must say i don't know much about cd formats (dext and koepi know much more than me regarding that). we can discuss different cd formats though if they have advantages.
thx again
avi
spyder
5th May 2002, 23:43
Does anyone here know the best way to get GCC working on Windows? I am looking for a version of GCC 2.96 or later(hopefully 3.0) with GCJ for Windows. I want to test my Java code compiled to native code that way. Since all I am using are base classes from JDK 1.3 (should be compatible with 1.1) my programs should work well with it. Maybe I could figure out a way to make a native CDXA MP3 player if I could compile my classes into a DLL and use it from VB(the only other Windows language I am good at).
spyder
6th May 2002, 02:39
To anyone who downloaded my modified JavaLayer app there was no manifest in the JAR for it to work correctly without unpacking so here is a fixed version. It works very well.
@Gawen:
Guess what "I just wanted to throw this in, and hell yeah, I know about wait-states and so on" is supposed to mean.
Please read my mails correctly :P
Regs,
Koepi
Belgabor
6th May 2002, 09:39
@spyder
As I gather from the info on the mplayer homepage GCC 2.96 is a buggy RedHat patch to 2.95 and, again from that page, GCC 3.0.X is still buggy, too. So 2.95 would be the best thing to use. (admitted, they mostly worked for me on my linux box, but at least 2.96 has some issues with some progs. If I didnt fear totally messing my system, I'd try to downgrade)
Regards
Belgabor
Hmm I wouldn't trust all what the mplayer team says. I've compiled mplayer with the 2.96 a lot of times without problems...
Since the gcc3.0 is a littlebit older now than a few days there should be no problem. The only thing with the gcc3.0: he is a littlebit more accurate with interpreting ansi-c++, so then you write code that doesn't conform to ansi-c++ the new gcc is bailin out earlier..
blIxi
Hello,
I've just update my GUI to use with the Mode2CDMaker 1.2pre from DeXT. I've modified the prg to take in account the source file name (don't know if it will bug the Image created but I've made some test with Deamon and CDRW on ogg, avi, mp3 files, and it seems OK). I've add a fixe entension to the files : .r, just to use corectly with my GUI.
The prgs are on my Web page : http://membres.lycos.fr/zorgzorg
A+
Belgabor
7th May 2002, 10:07
@blixi
That seems to depend on the options you use and on architecture. I had several versions or option combos which didnt compile with 2.96 but did with 3.0.2, others didnt compile with either (as I have no 2.95 I cant say if they'd have compiled anyhow though ;))
Regards
Belgabor
oddball
8th May 2002, 17:14
The only problem I can see with booting from CD and it auto playing the movie file (I'll assume movies will be it's main use here), is that if you have a TV out card you won't get TV out. You can view on the main monitor and that is all. Might be usefull for laptop users and those who don't pipe to TV though I guess.
Originally posted by oddball
The only problem I can see with booting from CD and it auto playing the movie file (I'll assume movies will be it's main use here), is that if you have a TV out card you won't get TV out. You can view on the main monitor and that is all. Might be usefull for laptop users and those who don't pipe to TV though I guess.
I have an ATI All-in-Wonder 128 Pro for the computer in my living room and it supports TV-out natively (even form the bios-bootup screen). I think all ATI cards behave similarly.
oddball
8th May 2002, 22:06
Yes. My Matrox G400 does the same I think with the correct enabling on the video cards BIOS. I think I tend to get probs in the mode booting back into Windows with it switching to 50Hz and having to manually switch it back in display properties from what I remember of trying it before. Not tried with more recent drivers however.
avig70
10th May 2002, 10:27
@nah
You have a small bug.
You treat shortcuts as if they were files and you put them in the files pane instead of treating them like folders and to be able to double click on them and go to the directory needed.
Also its not possible ot mark a few files at once and if the filesize is too small then a message box shows up and tells that the file is too small in some language that I don't recognize.
And a few suggestions:
1.) I think you should add some description near the panes themselfs to make the program more intuitive.
2.) Make the folder pane on the left side of the window and the file pane on the right side.
3.) Make a browse botton where ever you want us to find files or folders, I don't meen to impliment a file explorer like you did for the "list of files" but to make a small botton in the end of every line.
I've added a picture to ilustrate the changes. Here is a link ftp://ftp.ecitele.com/pub/Avig/untitled2.jpg
Avi
For those interested, today I've released the 1.2pre2 version of mode2cdmaker. Still in preview state because I've not added Form1 stuff yet, but you'll find a couple of neat features:
* progress & speed counter
* optional long file names support (ISO-9660 Level 2, though)
Apart from this there are some bugfixes, too (not very important, though) and small XA compatibility improvements.
Thanks to the tests made by MaTTeR tonight, finally one of his DVD drives was able to read Mode2 CDs. I've not included the new format yet since this will require a change in the DSF in order to read it so I'll wait to the next filter release, which avih is working on now.
Oh and about the long filenames feature, to use it just add a -l option to the command line. The file names will be converted to ISO-9660 Level 2 (i.e. all uppercase, and no spaces), and the last file extension will be replaced bythe default M2F2 extension. As an example:
mode2cdmaker "d:\movies\this is my movie.avi" -l
The movie would appear as: THIS_IS_MY_MOVIE.DAT
This is mostly a "play" feature, remember that in XCD it's very likely that only Level 1 file names are being allowed, at least until we add Joliet support.
webs.ono.com/de_xt
(you'll have to wait for the server cache to update)
Hi,
I've updated my GUI on the Avig70 advice, but still using 1.2pre from DeXT (with minor modif), because the 1.2Pre2 doesn't want to work with option -l. (I'm looking the code but have no time to fix it)
The prgs are on my Web page : http://membres.lycos.fr/zorgzorg
Sorry, my mistake. I was doing some modifications related to the Form1 support and I forgot to change something before compiling the release version. This eventually broke up the long filenames support.
I've updated the 1.2pre2 release with the new build, please get the new file, now it all should work as expected.
Sorry again...
Not sure this is a bug, or my mis-understanding of your command line
I did this,
mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v Spy_Game -e avi -l Spy_Game
The final output file turn out to be SPY_GAME.SPY_GAME, as you might guessed from the above I want spy_game.avi or "spy game.avi"
Yes it is a misunderstanding plus a side effect of the way the command line is analysed in mode2cdmaker. Perhaps I did not explain it very well in my previous post.
Yon do not have to put anything after "-l" option. This is a switch and tells the tool to use original, long file names instead of the short 8+3 versions. So the right command line should be:
mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v Spy_Game -e avi -l
Then let's analyze why the file extension turned "SPY_GAME". The last used option which takes a parameter is -e, i.e. the default file extension. The tool "remembers" the last option which takes a parameter so you can put several file names after an -m (and eventually -f) option as a separate file. -l is a modifier and do not count as "option" (now I guess I should change this). So it has the same effect as writing "-e AVI Spy_Game", which turns "Spy_Game" the default extension (the AVI one is overriden).
In the next version the tool will just show a command line syntax error in this situation.
Thanks for your report. Your feedback is an invaluable source to help me to make a user-friendly application.
Thanks for your report. Your feedback is an invaluable source to help.
No thank you DeXT, for making such a wonderful tool. :)
In the next version the tool will just show a command line syntax error
What if some wants some weird extension? How about do a preview of the output file. Something like the output file will be "blah blah.extention", would you like to continue?
Another question, with the long name support, does the spacing work? Or can you make the spacing work? In another word,
mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v "Spy Game" -e avi -l
output: "spy game.avi"
Originally posted by kxy
What if some wants some weird extension? How about do a preview of the output file. Something like the output file will be "blah blah.extention", would you like to continue? There is no problem at all with "weird" extensions, as long as the long filenames are enabled. The ISO-9660 allows for up to 30 character extensions. If -l option is not specified the extension will be trimmed to 3 chars (since we must accomodate it for a 8+3 filename).
This preview of the resulting file name is a very good idea. I'll implement it in the next version.
Another question, with the long name support, does the spacing work? Or can you make the spacing work? In another word,
mode2cdmaker.exe -o Spy -m "d:\spy game\spy game.avi" -v "Spy Game" -e avi -l
output: "spy game.avi" If we follow the ISO-9660 recomendations, whitespaces are not allowed. Althought it eventually "works" under windows, the resulting CD will not be standard and will likely not be readable under other operating systems. So at this point my tool will convert any illegal filename into a ISO-9660 filename (named "d-char").
There are two extended CD filesystem formats which could be used, named Romeo and Joliet. The Romeo one is pretty old and no specs are publically available through the Net. Joliet is the most common one but it's somewhat hard to implement. Anyways it's on my "TODO" list.
I have the suspect that Romeo is no more than an "illegal" ISO-9660, i.e. the file names containing lowercase letters, spaces an more than one extension. If that's the case this is pretty easy to implement. I'll try to find some information about this subject.
Beware that, as I already said, none of this will count for the XCD format except probably Joliet.
Thanks for your support.
jurij
13th May 2002, 19:31
hi! i need help!
I made a 790MB OGM file and when i play from hd it works, bt after converting to bin a burning i can't make it read from the cd.
The OGM contains divx5 video, 2 vorbis 64kbit audio files and 2 .srt subtitles files.
It is weird because with avi files it worked perfectly.
What can it be?
try to use daemon tools to mount the bin image. and then play the file from the virtual cd-rom. if it plays correctly then either the burn itself did something wrong or the cd got damaged (remember there are no error correction). if, however, the file doesn't play from the virtual cd rom then there's probably a conflict with the filter registration. in that case i suggest trying to use graphedit on the file from the virtual cd rom and see if it plays.
to use graphedit do the follows:
1. open graphedit.
2. insert new filter (dshow->RIFF/CDXA source).
3. select the file from the virtual cd-rom in the file dialog that appears.
4. right click on the output pin and select 'render'
if it worked ok you should see few more filters added to the graph, and you'll be able to press 'play' to play the file.
let us know how it worked.
cheers
avi.
jurij
13th May 2002, 20:46
the sintax i used was:
mode2cdmaker.exe -o Stargate -m "c:\stargate.ogm" -v Stargate -e ogm -l
i noticed that the ogm file in the cd is bigger that the one on the hd!
i did a test with a smaller ogm file:
on cd: 66.985.004 bytes
on hd: 66.186.225 bytes
plus i notced that with vorbis audio muxed i oggcut crashes!!!!
jurij
13th May 2002, 21:08
with daemon tool did the same thing that with the burned cd, it didn't play at all.
with graphedit it worked, i could watch the video and hear the audio tracks.
Now what am i suppose to do?
In my webpage (webs.ono.com/de_xt) you'll find a file called vcd_source_patch.zip, just download it and double clic on disable_vcd.reg. This will probably solve your problem.
This is a known problem that will be fixed in the next filter release without the need to use this patch. And you'll gain SVCD direct playing support without the need to install Elecard filters.
About this greater file size, well this is normal, there is about a 1% overhead since every 2324 bytes in the input file takes 2352 bytes in the CD.
I don't know if OggCut uses DirectShow to read the input file, but if it reads it directly it won't work because only DS-aware apps are supported.
Hope this helps.
jurij
13th May 2002, 23:34
i tried to disable but it still is not working :( HELP :((((((((
Hmmm, seems you have a conflict with another existing DS filter. Try to uninstall and third party AC3 and MPEG-2 filter (mainly Elecard), we have received some reports on this subject.
Try to drag & drop the DAT file in GraphEdit and see what's happening (which filter tries to take over it). This may help us to determine potential conflicts.
mustaneekeri
14th May 2002, 00:51
DeXT, can u say estimate or more accurate date when form1 files are supported by Mode2CDMaker?
jurij
14th May 2002, 08:57
OKKKKKKKK!!!!!
In the cd i burned the file is called stargate.ogm.
if i copy it to my hd and rename to stargate.DAT then it works.
if i drag stargate.OGM in graphedit it only gives me the filter OggSplitter
I tough it was suppose to work also if the files in the cd didn't have the .dat extension.
avig70
14th May 2002, 10:17
If it doesn't work with a different suffix, maybe its a good idea not to allow this option ???
I've looked at it, seems you cannot use a registered media type extension for RIFF/CDXA files because the original filter will try to take over that content. This is true for OGG/OGM and MP3, but not for AVI.
But as I said using the original extension is not recommended by any means since the file contents are no longer the same so you should use a new extension. This will be done the same way in XCD and MCD, too (custom extensions).
jurij
14th May 2002, 14:49
now what am i suppose to do? can i make it work with the ogm suffix in any way? what is it for to set the media type extension as i want if it won't work when .ogm?
Koepi
14th May 2002, 15:27
jurij,
I want to remind you that this is still experimenting stuff and thus can produce flawed CDs.
The "real" XCD won't necessarily be backwards-compatible and support the CDs you burned now.
If you're not willing to loose some CDs either use daemon-tools or leave your hands of this stuff until it gets retail ware ;)
That option is still useful if you burn avi to and m2f2 CD. AVI has riff-headers anyway and thus can cope with that.
mpeg1, mpeg2, mpeg4, ogm and mcf don't use riff headers and thus these headers inserted by the file reader (direct show) must get stripped again to make them playable.
Regards,
Koepi
@jurij: what you are supposed to do is, not to burn with OGM extension, but DAT. As I said OGM and MP3 won't work.
In order to be able to play that OGM file you'll need to delete the OGM media type extension in the registry, and I'm sure you won't want to do that. So that CD is pretty useless, sorry.
Koepi says it all, this is TEST stuff. Not guaranteed to work.
@mustaneekeri: I forgot, well I'll have to go out for a week starting with May 23, so I'd like to have it working before I go. This is my personal bet, but I cannot guarantee it of course.
Hi,
If some of you are interested, I've update my GUI for Mode2CDMaker 1.2pre2.
http://membres.lycos.fr/zorgzorg
Hope you could read French . :D
Just a quick note, Form1 is finally working. Still no releases since it's very limited at this stage, but definitely I have something to release before I go. I'll try to improve it in the next days, so expect a new release this weekend.
Apart from this, the next thing I plan to do is to add sub-directories support. I don't have a clear idea on how to implement this on the command line, perhaps something like this?
mode2cdmaker movie.avi -d stuff -f powerdivx.exe -d pics -f sarah.jpg nicole.jpg -l
This is supposed to generate the following directory structure:
movie.dat (form2)
stuff/
+powerdivx.exe
pics/
+sarah.jpg
+nicole.jpg
Tell me your suggestions about this subject, if any.
@Nah: BTW I added your nice page to my Links section.
The Belgain
16th May 2002, 22:14
I've just burnt my first movie using this method (a 770 Meg avi onto an 80 Min CD) and it's worked nicely. Really nice program.
What do people have to report about CDs becoming unreadable easily from scratches etc...?
Are certain containers (eg mp4) more tolerant to this? Does the codec used have any effect on error tolerance?
Would the multiple files be supported in the main directory?
In another word,
mode2cdmaker -f sarah.jpg nicole.jpg movie.avi -d stuff -f powerdivx.exe -l
This is supposed to generate the following directory structure:
movie.dat (form2)
sarah.jpg
nicole.jpg
stuff/
+powerdivx.exe
@kxy: Yes of course. You can mix Form1 and Form2 files the way you prefer. You will even be able to put Form2 files in subdirectories.
@The Belgain: I'm glad it worked for you. It should be pretty tolerant, the same as (S)VCDs, but of course the format used is very important in the error concealment (i.e. when you just can't read that sector, an AVI will probably freeze).
Just to note, the new tool will make sightly different CDs (it uses a new XA header which is more compatible with some DVDs), and the new filter will be able to read both CD types (and any possible future change here too).
jurij
17th May 2002, 07:34
how about using an external input file like this:
mode2cdmaker -load files.lst
and the file.lst may look like this:
\pippo.dat
\pluto.dat
\DONALD_DUCK\mickey.jpg
\UNCLE_TOM\i_want_you.mp3
.... and so on?
So it could be bvery easy to use a front end with it +
Command lines can't be longer than something like 256 characters i think.
raistlin2k
17th May 2002, 07:49
Great to see this Form1 working now!
Just three questions:
1. Can I use this for putting my graphedit-files onto the image?
2. Is it possible to place the form2 file into a subdir? Would be necessary for microDVD since I need the movie-file in a video_TS-folder.
3. I made a few test with graphedit-files using the "RIFF/CDXA Source"-DSF but after saving the graphedit-file and reloading it, all boxes are shown separately, no arrows between the inpput & output pins, so it doesn't work for saving. BUT microDVDPlayer needs this files! Any suggestions?
as we stressed few times before: it's still experimental and you should not try to put files for real archive. only testing is supported.
just wait for XCD, and then there will be error correction, and you'll be able to safely store your files.
regarding microdvd: i don't know how does it read the files, but there should be no problem storing form1 files. BUT if microdvd doesn't use dshow mechanism for loading the file then (at least now) it won't be playable with microdvd, since the dshow filter is the one that will handle the file protections and stripping. hence: no dshow reading -> no file protection and no 800M files (since the dshow filter also handles the stripping of the form2 File)
cheers
avi.
ps. i'm thinking of deviding the XCD spec to 2 parts: file level and cd level. file level will be a loose spec, that will only handle the reading/stripping/protections of a single media stream, while cd level will be the complete (hardcoded) cd structure, with all the menus, playlists, etc (and prob both will be handled by the same filter). so for using just standard 800M files in an arbitrary manner (i.e. for microdvd, while assumming microdvd uses dshow to read the files) you'll use the 'file level' xcd. and for complete, standard xcd (the one that we want to be read by stand alone players) you'll have to use cd level xcd. i think we can start with file level for now, which makes the spec finalization easier if we don't take the cd structure into account.
raistlin2k
17th May 2002, 13:20
Well, since microDVD is based on Windows Media Player 6.4 (needs to be installed!) it uses DShow for playing the movies. But for splitting a file with several audiostreams, so that only one audio-stream gets decoded, microDVD needs helpby graphedit. By using graphedit I define the filters that should be used to decode the file, select only 1 audiostream from the file-splitter (e.g. avi-splitter) and save it to a graphedit-file. microDVD Player then loads this graphedit-files to play the movie with just one language.
So i have to create a graphedit file for each audio-stream in the container-file. Since there is a microDVD-standard for file-naming a once created set of graphedit-files can be used for all movies using the same DShow-decoders.
Graphedit works with the "RIFF/CDXA Source"-Filter as well, movie is playable in graphedit. But after saving & reloading the arrows are away, manual connection of the output-pin of CDXA with a splitter doesn't work anymore, WHY? This must be a bug in your filter, all other sources work well, like it should be with graphedit, a tool by microsoft, the author of DirectX ;)
Any suggestion?
Raist
P.S. I know well that your system is just in development, I'm not using it yet for archiving my movies, I'm just testing it a little bit. Hope I can help you with my tests :)
Belgabor
17th May 2002, 13:39
@DeXT: for adding multiple files I'd support jurij's idea of an input list file, but I think it would be a good idea to extend it a bit like this:
<source>,<dest>,(1|2)
with <source> being the path/filename of the input file, <dest> the path/filename of the file on the cd and (1|2) whether it should be written form1 or form2.
Regards
Belgabor
@raistlin2k:
ok, i need more info about where are these graphedit files are stored, and with the 'final' product of yours, what does play, and what doesn't.
i'll try to give few hints anyway:
1. if you put the files (graphedit) on the cd as form 2 files, then nothing can read them correctly, except for the filter (or a special os driver with similar functionality to the filter, but none exists afaik), but since microdvd doesn't use the filter to read a graphedit file, it's not read correctly.
possible solutions:
a. try to put the graphedit files on the hd, and point microdvd to these files. let me know what are the results
b.wait for form1 files to work as well, and store these files as form1 when u put them on the cd.
c. make an image of the vodeo file ONLY (and keep the graphedit files on the hd without making an image with them). burn (or use daemon to mount). copy the video file from the cd to the hd. put the graphedit file/s (unmodified, as saved from graphedit), in the same directory structure that microdvd expects. try to play. lmk the result.
2. regarding the pin configuration. the filter tries to select the pins media type automatically, by the content of the file it was opened for. so if microdvd tries to build a graph with the filter without supplying a file, a graph won't be built. that could be a reason. but i suggest you try solutions a,b and c first. if they don't work, i can supply you with a filter compiled with a fixed media type, to make further tests.
so, do test these options and let me know how did it go ;)
cheers
avi
raistlin2k
18th May 2002, 08:44
Well, thanks for the hints, but I've already done this tests, since it was clear to me that the graphedit-files are not readable for microDVD if they are in form2.
I made the tests again last night and grabbed two pictures from graphedit.
"Working" shows Graphedit after clicking on "Render File" and select the DAT-File from image mounted on Daemon;)
for microDVD Player I have to save the graph build by graphedit into a file, microDVD Player cannot build a stream with only one of the available audio-streams!
So I saved it to a separate file and then I reload it with graphedit, as usual, to check if it's working correctly. (microDVD Player has no good error-information, in graphedit I can see what's going wrong) Well, have a look at it for your own "not working":(
I tried to re-connect the pins in the broken "not working" - window, but didn't work!
Any idea? Could you send me a filter fixed to ogm?
Raist
P.S. I've just forgotten the microDVD-specs:
Here I use the dat-extension for testing, for microDVD it should be "vts_01_1.vob" in a "video_ts" folder, together with the graphedit-files, renamed also to vts_01_2.vob, vts_01_3.vob etc.
microDVD doesn't care about file extensions, so it's just for cool looking!
In the root-dir there is a mdvd.ini that tells player all infos about the movie (the related files, languages, menu data)
P.P.S. microDVD supports aleady menus, chapters,all DVD-features. There are also special tools to create a 1:1-copy of a original DVD-menu, I did this with several movies, e.g. Star Wars Episode 1, a really cool menu:cool:
What do you think of using microDVD Player for the CD-level of XCD specs?
P.P.S. I haven't posted an attachment yet in this forum, I see it's up in edit attachment, how do I make it available for you:o
microdvd is closed source, hasn't been updated for quite a long time (afaik), and might go commercial.
so imho, microdvd is out of the question. supporting microdvd is not our 1st priority, since we still have to work on xcd itself, before trying to soppurt specific players.
sorry, as i don't know much about microdvd (i used it few times only). maybe you can help buy studying exactly how it works, and find out WHY it doesn't work with the mode2 filter. but i'm affraid i don't have the resources to help u more with that issue atm. we might look into it later on though, when xcd itself has made some advance.
cheers
avi.
ps, i don't mind trying to look at this issue if someone gives me more detailed info. but i'm not gonna test it myself atm. regarding the attachments, you'll have to wait till a moderator approves them, or just supply a link to an external page, that contains your images.
pps
i missed your request to ogm fixed filter. send me your email on this thread or on a PM, and i'll send it to u.
raistlin2k
18th May 2002, 11:39
I'm also very unhappy that microDVD had no updates for a long time, and that the last release 1.3 is not available for free anymore. So I still use version 1.2
I understand that you don't want to support such a player. The good thing is that it has perfect working menus, PowerDivX is not so good on this issue. Since I know very good how it works, wouldn't it be a idea to base your menu system on this one? because there are very good tools out there to translate a DVD into a microDVD menu. If your filter were able to use such a menu, it wouldn't be necessary to support microDVD itself, language,subtitles and chapters are choosable via OGG DSF.
Another question: How far is the XCD muxer from (beta)release? Will you support OGM for error correction issues or will it be better to use MCF as container? Which subtitles will XCD support by MCF, like OGM (OCR-rippped) or like VOBSUB (pics)? I prefer OCR-ripped subtitles, being very compact.
Raist
You can try the test4 release which included an OGM-fixed filter. I don't have a clear idea about this issue but I think it may be related to the Media Type issue since our filter needs to load the file in order to recognize the Media Type. If that's the cause it probably will work with the OGM-fixed version. But neither avih nor me have got enough DS knowledge to look deeper at this issue.
raistlin2k
18th May 2002, 14:23
Test with filter "test4" failed, too.
So I will send microDVD-Player into retirement.
Something about mcf:
Will it work with vbr-mp3?
Just tested ogm with such audio, didn't work, audio-stream can't be decoded after muxing.
Any betas for mcf muxer yet?
Raist
Koepi
18th May 2002, 15:35
Better use OGG audio in an ogm.
Superior quality at those bitrates.
To nah:
I have, in my home, WinXP, english language edition.
I have tried your GUI, but i always get an error saying that it can't find a language dll and i need VB6FR.dll
I believe that this is the error, sorry for not being sure, but i didn't write it down :( (My mistake, sorry)
In yout txt it says that one needs VB6 dll's, and after a search in google, i downloaded a VB6 SP5 from microsoft, but it didn't helped, i still got the error. Probably it wasn't the update i need.
But here in my work, where i have Win95B works fine.(?)
This error was only in the GUI, i can't speak for Mode2 CD Maker. I will try it later, using command line.
EDIt: Just went to your site and saw that you have a Package.zip and an update file. Probably all that i need. Sorry for not looking first and post later :(
Koepi
20th May 2002, 10:37
rui,
you might want to try it here:
http://www.microsoft.com/downloads/release.asp?releaseid=28337&PopList=4
You could get localized versions of the runtime libraries as well there.
Maybe you just got an "upgrade" package, so this is the full VB6 SP5 runtime - but read on on that page yourself ;)
I couldn't check this yet since I'm a little busy, sorry.
Regards,
Koepi
Many thanks, Koepi :)
Downloading right now. I don't know if this is the same file i got from microsoft that i mention in my post, but will try later in home, where i get the error.
But probably, by using the package that Nah has in his site will solve the problem also.
But maybe doom9 should mention this in the guide, because more could have the same problem has i had.
Agree, this is all experimental stuff, and Nah says in his txt that one needs the VB6 dll's, but it wouldn't hurt to mention this in the guide also. As always, this is only my humble opinion.
Well I finally released the new mode2cdmaker 1.2 (final) with Form1 files support. I was waiting for avih to release the new filter but since seems he has had some last minute problems I've chosen to release a modified test5 filter which is able to read CDs made with this version. So I'd recommend you get both from my homepage.
This new filter is needed since mode2cdmaker now uses a different XA subheader which has proven to be more compatible with existing CD/DVD drives, thanks to the tests made by MaTTeR.
You should note that there is no subdirectories support yet, this feature was scheduled for next release.
You can add any Form1 file through the use of a new option, "-f", just use it like the old -m option. You can put any kind of file such as readmes, executables, drivers, photos or the like. An example:
mode2cdmaker -l -m movie.avi -f player.exe readme.txt autorun.inf
Remember that if you don't add the "-l" option all file names will be trimmed to 8+3 chars, to maintain compatibility with ISO-9660 Level 1, and the movie files will be saved with VCD-like filenames.
Oh and the tool now shows a total estimated CD size so you can get an idea on which type of media you'll need in order to burn it.
Get both (mode2cdmaker 1.2 and riff-cdxa-filter test5b) here:
http://webs.ono.com/de_xt/
Hope you like it.
jurij
20th May 2002, 15:19
very good DEXT, very good....
Do you know if the new 5b filter is compatible with CDs burned before?
Yes of course. It reads all CDs made with previous releases as well as the new ones. You can install it safely.
jurij
20th May 2002, 18:28
in what way xcd may not be backwards compatible in the future developement?
Koepi
20th May 2002, 19:10
I've finished a first version of a "XCD Backup Creator" which curretnly just works for *.ogm (since I know which data has to be saved there - it's easy, just the first 64kb ;) ).
If I now find what to save from an AVI, MP3 and an MCF we could start the real thing :)
After I finished that support I could strip that down to a command line tool.
dext, I think we need directories very soon - if we have "-m myvideo.ogm -d secure -f back0000.xcd -d codec -f filter.exe" this would be something like the basic XCD! :)
But we have to reewrite our specs as well I think as we're progressing in the implementation.
Well, just some infos about my progress here :)
Best regards,
Koepi
@jurij: well my idea is, that the XCD filter should be backwards compatible, i.e. it should be able to read non-XCD content as well (i.e. pure Mode2 content). So you should be able to read a movie recorded with my tool now, at the expense of lacking file protection of course.
So in fact it's up to the user if he wants to risk not having file protection. But anyways if a unprotected disc starts getting reading problems you should be able to extract the movie and burn in a real XCD with file protection, too.
@Koepi: this is great news! I'm willing to see that piece of software running.
Yes I already know subdirectories support is a MUST for XCD but it's also the only thing pending to make my tool fully usable from the XCD side at least. The problem is, I'm leaving in 2 days and won't be back until day 31 so I'm afraid I won't be able to have this finished before I leave.
About the XCD file layout, anyways I think it should be desirable that the filter would be able to read backups from the current directory as well, so you can load movies from the HD before burning to a XCD. This way you could also start using it without the need for subdirs.
I would like not having to put movie files in a separate directory since in most cases a CD will contain a single movie so a single file in the root dir would be desirable (with backups in a separate dir). So in your example (adding -e XCD, and assuming XCH for header/backups):
MOVIE001.XCD (full movie if form2)
\SECURE\HEAD0001.XCH
\CODEC\FILTER.EXE
So the filter would search for the *.XCH file in the current directory and if not found would try in SECURE, HEADER or whatever it's called. If finally it's not found it should assume it's an "old", unprotected file, and should play as it is. So we maintain the backward compatibility.
It's just an idea. I guess we are starting a XCD specs discussion now :)
Koepi
20th May 2002, 20:16
DeXT,
this sounds all very reasonable.
I think avih wants XCD to hold up to 10.000mp3s in a flat dir (MPEGAV dir on VCD), which is a little problematic imho. A root dir should only contain up to 512 entries if i remember correctly.
I left the with the HEADERS stuff since we went over to store directly _chunks_ from the stream, regardless if they contain headers or data.
So it's a backup of a small region in the file.
that's where the name
\SECURE\BACK0000.XCD
came from.
I have no problem with the media files residing in the root directory.
Avih wants some flags for his filter to see if a media file is stored m2f1 or m2f2...
Dunno how to solve that, I would think it's not necessary to have a XCD with m2f1 files on it - it can be easily done with other software then - I see no benefit of storing data this way.
But let's see how things evolve :)
Best regards,
Koepi
jurij
20th May 2002, 21:04
Does anyone have idea about how can I make a copy of a cd burned from a .bin created by "Mode2 CD Maker"?
Both nero and cdrwin (which i used to burn that cd) seem not to recognize the sorce cd.
Koepi
20th May 2002, 21:20
Ok pals,
created and (over)burned my first XCD!
Containing:
back0000.xcd
mymoviename.dat
filters.zip
we really just need directories now, make the filter read the backXXXX.xcd files and we're done ;)
My DVD rom usually doesn't recognise many discs. But the XCD got recognised on first try.
The image was taking up 80min21secs, the CDR should end at 79:55 according to nero - but it worked like charme, no error message or whatsoever :)
I'm amazed.
Let's hope our DSF will stay backward compatible ;)
Ok, i too have made 2 successful XCD burns :)
Both were avis with 796 MB each, and were burned in 700MB cd's. But, like the compatibility txt said, my Samsung 616T DVD rom (16x) couldnt read them :(
But do not fear: my HP 9100 burner didnt had any problems with them :D
But now I am messing with my DVD firmwares. I found out this site (http://wald.heim.at/sherwood/530742/dvd/samsung/index.html), which has loads of firmwares for my model (and others)
I will try if I can get any to work so I can read the DAT in the DVD.
Ah, the life with a 798MB burning method is wonderful :D :D
@jurij: This is strange, I'll test it but perhaps this is related to the known reading problem with some drives.
@Koepi: Man, you probably are the first person in the world to make a "real" XCD! This is sweet. Now we just need something to read it :) Well in fact avih added some code related to XCD in the new filter but not a full implementation yet. It's just a base but looks promising :)
@rui: This reading issue just don't let me sleep quietly. I wonder what's the cause, and why it only fails on some drives. I have a feeling that maybe CDR-Win is not burning the CD properly, can anyone confirm this with a "real" VCD burned with CDR-Win? If that's the cause, perhaps adding Nero image format output could fix the issue once for all. Damn this was in my "TODO" list but I forgot it almost completely. Now I guess I should start working on this, too. I already wrote some functions to output a NRG 5.0 image when I was working on cdi2nero, so it shouldn't be too difficult to update them to make a 5.5 image.
Koepi
20th May 2002, 23:15
regarding CDR-WIN i have to say that it ALWAYS made trouble.
I myself forget about this once a year and 1 week ago trashed 1 CDR with this f***ing wannabe-program.
Head over to http://www.fireburner.com/ (I hope the url is still correct) and burn your image with that proggi - it's absolutely reliable, even if it doesn't detect all features of your drive. It still produce "bomb-safe" CDs.
and hmmmmmmmmmmmmm
Am I really the person with the first XCD?
I sent you the proggi so you could have been faster!
;)
Greetings,
Koepi
Hello,
too many post to read since my last one (some holidays ! :) )
I will update my GUI to take in account the last release from DeXT.
And I will soon be able to really burn my 800Mb videos !
Good job to all of you !
A+
hehe, same here... i was reading this thread this morning, and now, WOW ;)
anyway, as dext said, the filter was rewritten, and now there's an XCD_Media_Reader class to handle m2f2 files. it's completely portable and free of win32 or m$ api (i.e. uses only fopen, fseek, etc, and only 'normal' types such as int and long. it already reads svcd and vcd as well, and is usable with the free fraunhofer freedvd mpeg2 codecs. so for one thing, it's an end of the commercial apps only for svcd playback. this new class also offers the infrastructure for the backup file.
regarding backward compatibility: it will be there (at least i'll make every effort to keep it, it's 99% it's gonna be compatible with 'old' files.
regarding directory structure. as i noted before, the xcd spec will split for 'file level xcd' and 'cd level xcd'. this separation will allow us to concentrate on the file-level backup protection (header structure), and make it work, before we continue to the cd-level, which will have the hardcoded directory structure and the other features as playlist and menus. the filter will 1st try to find a backup header from the current directory, and then from the 'hardcoded' directory ('SECURE' sounds good enough to me).
regarding the backup structure: koepi and myself have been discussing it quite a lot in the lasrt few days, and we're getting somewhere :)
@koepi: the m2f1 is for 'unprotectable' files/formats (i.e. if we store a jpg, as part of an XCD cd (i.e. as a bg for a menu), we should protect the whole file, and since it doesn't make sense to put the whole jpg both as m2f2 file AND in the backup header, it seems logical to store it as mode file only).
as for the release date of the new filter. dext has changed the registry system a bit, to overwrite m$'s vcd reader filter (so no more conflicts with that filter, a problem which some ppl had, and used dext's patch to fix that). we're working tightly on that (the filter is fine, it's just the install script that giving us a headache on my pc, but working fine for dext). we're gonna get there ;)
great to see all this work, i really hope xcd will be as cool as it now seems it can be ;) .....
cheers
avi.
regarding backward compatibility again: the xcd backup creator may NOT be compatible with future versions...
i suggest not to use the backup creator untill we officially announcd the first spec (should be real soon).
cheers
avi.
Koepi
21st May 2002, 03:13
I suggest I finally do what I planned yetserday since I only get "stones in my way".
Test: Video.Ogm 750Meg
CD: 700/80min RW Premium
Writer: LG: GCE-8240B.
Lect: LG GCE-8240B.
Lect: HP 4X mmm not remember the ref#
Burner: Nero 5580
All work like a charm on these, the filters need a restart to rec the file, but all work ok.
Later I will post with a Lg dvd 16x
You guys make excellent works, go on! :)
Cheers
@DeXT: My burn was made using Nero 5.5, i had forgoten to mention that, sorry.
You mention to add Nero image format output. If i understood you post correctly, mode2cdmaker currently uses CDR-win image output format?
That means that the problem of my Samsung DVD Rom not reading the created xcd wasn't of my burner software, correct? I will try fireburner, like Koepi recomends (i have learned that koepi's advices are always good ones ;), but my hopes aren't high.
@Koepi: the link is correct. Thanks
Hi again.
attached is the latest RIFF/XDCA filter (test6).
Changelog:
----------
21-MAY-2002: test6:
- VCD and SVCD playback support added
- filter rewrite (for portability and future support for error protection)
- improved media detection
- file name changed from asyncflt.ax to xcdsrc.ax
- registry system modified to override ms VIDEO CD Source
(which doesn't read s/vcd correctly, and may introduce conflicts.
the uninstall script put back the original registry values)
SVCD playback may be a bit skippy since high bitrate is involved, and we didin't add buffering yet.
the filter DOESN'T support (=use) the backup files now. but the next version prob will.
this is a binary only release. the sources will be included again with the next release.
any feedback is welcome (especially regarding vcd/svcd).
enjoy
avi
ChristianHJW
21st May 2002, 14:04
... its really incredible what big steps forward you guys have been doing recently ;) !!
Koepi
21st May 2002, 14:52
I sent a "fixed" version of the XCD backup creator around to avih and dext which goes conform with what avih demands to be changed (changing the version-indicator byte to a plaintext info).
I coded it very generic now and thus it should be easy to check in other changes, the basic construct is there.
Let's see what happens.
Koepi
21st May 2002, 16:49
My setup:
win2k sp2
(development system, but shouldn't matter here)
256mb pc-133
LiteOn DVD LTD 122
With the filter installed my test SVCD plays back fine/normally, only seeking times are a little reduced.
Maybe you have DMA disabled in your setup avi?
Well in fact it's not Avih but me the one having problems with SVCD...
This is an old K6-2 450 with a shitty 8 MB Banshee card, and I'm reading with my 24x Acer burner. This computer isn't powerful enough to play SVCD/MPEG-2 in real time (even DivX), but I just noticed that with Elecard splitter (which does support direct SVCD reading) both the playback and the CD reading is smoother (not fully smooth of course), but with our filter and the default MPEG-2 splitter it's sightly more skippy. I think this difference is due to the lack of buffering, since the M$ file reader probably does some basic buffering, which we lack (but will be added soon).
Anyways any "modern" computer should be able to playback this with no problems, perhaps only a small increment in CPU usage, when compared with Elecard. But Elecard is shareware and this is 100% free :)
(any tests from anyone would be of valuable help, too)
Koepi
21st May 2002, 17:11
Never call the banshee shitty!
I loved my old 16MB banshee, it was amazing in it's time!
But you're right as usual, with a little buffering (maybe reading ahead ~1mb?) it should work way smoother.
Shouldn't be too hard to implement, a simple malloc() or buffer=new char[1024000000] should do the trick ;)
Regards,
Koepi
jurij
21st May 2002, 18:48
@koepi:
Hi man, I don't understan what "xcd backup creator" is.
is it a program? is it released?
Koepi
21st May 2002, 18:51
Hi,
yupp, XCD backup creator is a program that creates the "security files" for those mediafiles we're going to burn in mode2.
Tonight we'll finish the spec of the file-format, some things are a little unclear now, but tomorrow there will be a release hopefully (I'm confident that we fix the structure tonight so the tool could be available a few minutes later).
Regards,
Koepi
avig70
22nd May 2002, 08:58
@koepi
It seems to me that the CD-ROM reading takes allot of time from the player application and that is the part that should be the most optimized right after decoding the movie and copying of the video data to the display adaptor which takes the majoraty of CPU time.
After reading a little on the subject, the thing that takes the longest time is the searching for tracks on the CD-ROM and actually reading the compleate track is a fixed time and can't be optimized through software in a level as high as we're dealing with, so to make the filter as fast as possible the buffer should have the multiples of track size or multiples of the biggest track on the CD (I'm just not shure how many sectors are in a track and if it's a constant number or not) or may be a little more then that so it could be filled just before it runs out of data.
It should also use unbuffered read functions since they are faster and we impliment the buffer our selfs.
I couldn't learn more on the subject because I didn't find articles that explain optimized reading algorithms from CD-ROM that also contain source code for me to look at.
Any help is wellcome.
avi
avi, i thout of makeing it multithreaded, suth that the buffer filling is asynchronous. so one thread read aheah and fills the buffer, while the other thread get data from the buffer uppon user demmand.
i'm not using aspi atm to read the data, but simple file os access (i.e. fopen, fread, fseek etc). so atm i don't have low level control over the cd.
i will add bufferring a bit later, as we're now making progress on the spec, and first i'll implement the backup functionality in the filter.
first correctness, and only then optimizations.
cheers
avi.
Koepi
22nd May 2002, 11:21
Agrred.
;)
Btw., I think we can't make the buffer as big as the longest track - who has > 800MB of memory?
The average standard setup is still dealing with 128 or 256 MB of RAM.
So a buffer of 1MB sounds perfectly reasonable to me - if we even optimize it (like: buffer down to 15%, fill up at least to 85%,... need an synchronous thread for this ;) )we should be fine with 512kb or less.
If we want it to work on stand alones later on, we have to take low memory conditions into consideration.
Regards,
Koepi
avig70
22nd May 2002, 11:43
@koepi
When I saied track I ment the physical track on the disk which contains a number of sectors, I'm not shure if its constant or not.
The whole CD is devided into tracks which is like a ring.
The tracks are devided into sectors which are equal sections of the track/ring and they have a constant size but contain diffrent stracture from one implimentation to the other and thats how we gain our extra space.
We impliment our "data" files in a video/audio kind of sectors that anable us to store more information on the same physical media.
The time you save is by reading compleate tracks to the buffer, and not a random number of sectors that just happend to fit into 1MB~ of buffer.
I forgot to mention that the smallest data size that you can read is a sector, even if you read one byte, a whole sector is going to be read and then only one byte is returned to the application, same goas for hard drives.
The memory in the computer doesn't work like that, you can access much smaller data stractures, such as 32bit, as long as they are not smaller then the data bus of the CPU.
@avih
Multythreading is the way to do this with a pipe sharead between the threads, and messages running between them to change reading positions and error messages.
I see that you are trying to stick to non OS specific functions which is great but for low level I/O I'm not shure thats possible, my question is whether you thought of some kind of an I/O layer that buffers between the OS and the application or have you implimented the read function straight in the code ??
But like you saied, the time for optimizations is a little bit later.
Thats it for now.:cool:
Keep on the great work.
avi
Koepi
22nd May 2002, 11:53
Avig,
now i know what you mean, and yes, you're right.
But the number of sectors that fit into a small buffer (we could make it a ring buffer, would work even smoother and would be a software representation of the physical world ;) ) isn't really random. We should make the buffer size as a multiple of our sector size, e.g. 2352 or 2336 bytes, this is the kind of alignment we need.
I'll search about tracks/sectors on CDs later on, but maybe we really don't need such a huge buffer as ~500kb - depends how much data is stored in 1 track of a cd (800 tracks per inch if i remember correctly, would be something like a few kb per track).
Regards,
Koepi
Hi there again. I was not sure about releasing this since I'm leaving tomorrow early and I won't be able to read the reports until I'm back in May 31. But I've done many tests with this and I think it works fine. Anyways I'm not deleting the previous release so if you think there is something wrong just use the 1.2 release.
Mode2 CD Maker 1.3 with the following new features:
- multiple subdirectories support (only for Form1 files)
- ASCII filenames (w/lowercase and whitespaces)
- removed old VCD-like filenames
To add subdirectories to the current ISO structure just add a -d option followed by a directory name. All subsequent Form1 files
after this option will be saved inside this directory instead of root. You can do this as many times as you want, but all subdirectories will be added at root (i.e. no nested subdirs support). An example:
mode2cdmaker -m movie01.avi -f readme.txt -d utils -f player.exe player.ini -d SECURE -f movie01.xch
This will generate the following directory tree:
MOVIE01.DAT (Form2)
README.TXT
UTILS\PLAYER.EXE
UTILS\PLAYER.INI
SECURE\MOVIE01.XCH
I know this is not the best method but I'll improve it later, probably through the use of a file list.
To avoid these ugly ISO-9660 filenames use the -a (ASCII) option. This will tell the tool to use ASCII character set which supports whitespaces and lowercase letters in the filenames. To use long filenames along with this you'll have to specify both options (-l -a).
And now by default the Form2 files will be saved with the original name instead of the ugly AVSEQ01.DAT (but trimmed to 8+3 unless you add -l of course).
Oh and good news, tonight in an IRC chat Avih, Koepi & me finished the first XCD specs so Koepi will be able to release a 100% compliant tool very soon. Definitely XCD (File Level at least) is here sooner than we expected.
Hope you enjoy it. I will read reports when I'm back. See you!
http://webs.ono.com/de_xt/
(wait until ISP cache is updated)
Koepi
22nd May 2002, 21:44
Great work De_XT! :)
I'm glad that you could release a new version this fast!
So it's my turn to finish off the backup creator to support the final spec avih sent around today. It may take some hours though since we're once again having a small party here :)
Anyways, enjoy your time off,
CU then :)
Regards,
Koepi
TheXung
23rd May 2002, 01:28
I must comment that this is the biggest thing that has happened to ripping since Nandub.
Oletros
23rd May 2002, 19:55
I have used mode2cdmaker 1.2 with riff test5 without any problem.
Last film I burned was one done in xvid with 2 ogg stream and subtitles. It sized 803 MB and plays ok.
Today I have used mode2cd 1.3 with riff test6 to make an image with this parameters:
mode2cdmaker.exe -m "Rocky Horror.ogm" -o trhps -v TRHPS -e DAT -l -a
I load the image with daemon tools and load the file with bsplayer. I can only hear the sound but I don't have any video.
If I load the .DAT file in graphedit it plays perfectly.
Any clue for that behavior?
Thanks
(Excuses for my bad English)
Just wanted to say that I had no problems in creating a mode2 cd with an avi movie, burning at the same time the subtitle files, and using with no bugs at all direct vobsub.
Nothing big, but I thought it was worth this little post, to someone out there who is wondering (like I was) if direct vobsub would work ok with this new burning method.
I used mode2cdmaker 1.3, and riff-cdxa filter 6, with this command line:
Mode2cdmaker m movie.avi o newmoviename e avi f newmoviename.idx newmoviename.rar
I only used the command e avi, so the new file extension wouldnt be DAT but AVI, and that way one can load the movie even from windows explorer, and not only with media player. But it isnt necessary for direct vobsub to work. I tried burning with the default DAT extension, and direct vobsub worked very well
Hope the Mod finds this post useful enough so he doesnt delete it;)
EDIT: Just saw that Oletros also burned a movie with subs. I also have problems when trying to load the DAT file in bsplayer (crashes)
Koepi
23rd May 2002, 21:45
Might be an issue of BSplayer. Can you test with WMP 6.4 again please?
Btw., if you change the extension to AVI with an *.avi source file you don't have any troubles since avi files already contain RIFF headers. :)
Just don't try that with ogg, mcf or mp3 ;)
best regards,
Koepi
Oletros
23rd May 2002, 22:06
I have played it with WMP 8 and Zoomplayer and it plays like a charm. Could it be a bsplayer issue.
By the way, is there any option to hide the subtitles muxed in the ogm? I haven't found it. I have movies with 2 subtitle streams and movies with 1 and I can't hide them.
For information, I have burned the image with a AOpen 24x and I can play the cds with it and with my Pioneer 16x DVD.
Thanks Koepi, avih and the rest of people for you great job.
Koepi, like Oletros said, with media player 8, and with media player 6.4, plays just fine both the avi and dat extension.
But, when having avi extension, and trying to load on bsplayer, it gives a message of unknow format. When trying with dat extension, it crashes.
I will experiment more, because i really like the posibilities in bsplayer of loading winamp DSP filters.
Oletros
24th May 2002, 09:06
I have only tried to create the image with form2 extension equal to DAT and with this extension bsplayer loads the movie, it doesn't crash (I haven't used AVI extension rui).
When you watch ds filters it shows all the necessary codecs loaded (xvid decompressor, ogg decompressor, vorbis splitter) and you can hear the movie but you can watch it.
It's a really strange issue because you can move around the movie, you can use the chapter list muxed in the ogm, etc.
bsplayer doesn't use a 'standard' dshow chain. it's a known facts, and it has advantages and disadavtages. one of the advatages is that it uses it's resize module, and can overcome crappy hardwarew resizers. but that's the situation atm.
if bsplayer can't play an mode2form2 clip for some reason (due to unique file handling), there's nothing we can do about it, except writing a plug-in (is that possible??) or let the author modifie the player to use the xcd library (when it's finished).
currently we're working on a dshow filter only as it allows most players (wmpx.x, zoom player, powerdivx and more) to play the file. when we're satisfied with the dshow dshow filter, we'll hopefully start making other plugins (like for mplayer, bsplayer, winamp, etc).
sorry for now
cheers
avi
Oletros
24th May 2002, 10:53
Thanks for the answer avih.
Hi,
I've just updated my Mode2CDMaker_GUI to use with Mode2CDMaker 1.3.
Not enough time to test all items I've added.
http://membres.lycos.fr/zorgzorg
MaTTeR
25th May 2002, 18:41
Thx for the update nah.
Anyway you can start naming the archives with version numbers? It would make a little less confusion for me;)
mustaneekeri
26th May 2002, 09:48
Concerning BSPlayer i had no problems what so ever playing a .dat file from the image mounted with daemon tools.
I used latest Test6 filters, latest BSPlayer, Latest GUI from Nah. Mounted the image with Daemon tools (970MB .dat file (Ogg container with DivX 5.02 video and Vorbis audio) and a form1 .sub file).
The movie played perfectly with BSPlayer from the virtual DVD-drive and with external subtitles and all.
Im now goin to add BSPlayer straight to cd try to burn the image to 99min cd-r.
Reporting the result later...
Burned the image file 981Mb/97:14 containin 20 form1 files and 3 folders and one form2 media file.
Burner: LG GCE-8160b
Reader: Liteon LTD-163
It works like a charm.
Koepi
26th May 2002, 11:14
We're close!
I just sent around rc1 of XCDBackupCreator to avih and DeXT for reviews of the correct implementation of our spec.
:)
Regards,
Koepi
P.S.: some input is still necessary to find out which are the vital parts of avi, mcf and mp3... ;) (the first 128bytes, the last 256bytes, ...)
ChristianHJW
26th May 2002, 11:15
Originally posted by Koepi
I just sent around rc1 of XCDBackupCreator to avih and DeXT for reviews of the correct implementation of our spec.
P.S.: some input is still necessary to find out which are the vital parts of avi, mcf and mp3... ;) (the first 128bytes, the last 256bytes, ...) ... asking for help on MCF mailing list now ;)
jurij
26th May 2002, 13:26
@koepi: "..I just sent around rc1 of XCDBackupCreator to avih and DeXT..."
i tought DeXT was not gonna be back online before the 31st.... :) (haven't seen any new post from hims since he left...)
What do you mean we are close if it still miss the whole parts about avi, mp3 and mcf? you only seem to us to have completed the ogg part.
Let us know a little bit more :)
P.S. you all are great!!!!!
Koepi
26th May 2002, 13:34
Since I only have real information about how ogm has to be "secured" in the sense of which information of the media stream is vital, i first coded this.
MP3 will be added soon as well, I just have to find out about id3/id3v2 (how much bytes are reserved for them in the beginning/end of the file?).
I hope this is the information you wanted to have.
EDIT:
PS:
I wrote CLOSE, not FINISHED.
Guess why.
You shouldn't sound that "bad tempered" when you're posting in a development thread. All those issues WILL be addressed.
I'll stop posting about progress when _everything_ I post is bashed at.
jurij
26th May 2002, 13:39
well if ogm is working i believe an OGM release would be fine since i guess most of us has moved to ogm (being around this tread all day, eh eh...)
Belgabor
26th May 2002, 15:06
Originally posted by Koepi
MP3 will be added soon as well, I just have to find out about id3/id3v2 (how much bytes are reserved for them in the beginning/end of the file?).
Afaik, id3v2 has no fixed size in the manner of always being say 256 bytes. its variable and ususally at the end of the mp3. id3v1 has a fixed size (which I dont know) and is at the beginning of the file.
Regards
Belgabor
Koepi
26th May 2002, 15:30
About mp3 I found following information:
The spec for ID31 is simply 128 bytes at the end of the file divided into the following fields[...]
So I have to store the last 128bytes of an mp3.
The ID3v2(.x) tag is at the start of an mp3 and can be _any_ size *grrr*
Still figuring out how to find out the size information, www.id3.org is the address I'm searching now.
First results:
(from http://www.updatestage.com/previous/000501.html )
1. Get the entire ID3 info length from the ID3 header (byte 7-10)
2. Read byte 6 (flag byte). Value > 32 means there is an extended header
3. If there is an extended header, get its length from bytes 11-14 and read to the end of the extended header, otherwise the read head is already positioned before the first frame
Problem is, there might be a copy of this header at the end of the mp3 again (sic!) or it could _only_ exist there. I think I'll support this version:
Storing the id3v2 header (if present, detection through the chars "id3" at byte 1-3), fetch the length from byte 7-10 (int32 hopefully). Second segment stored is _generally_ the last 128bytes of the mp3.
Hu
Tronic
26th May 2002, 15:49
MCF protected areas:
http://mcf.sourceforge.net/cd/mcdcd.zip
The code is in mcfcdwr.c
Koepi
26th May 2002, 16:03
Hi Tronic,
the only actual value I found in those sources was 0xA8 - do you need these first 168 bytes _only_ as backup to keep the stream playable? Do you have a "rule of thumb" how much data you need to playback such a stream?
We don't want to in-depth analyse and parse the different media types as therefore much knowledge about a format must be implemented into the programs (we have still somewhat the standalone manufacturers in mind ;) ).
Our attempt is to store the backup as m2f1 instead inserting multiple (vulnerable) header copies into the m2f2 part of the CD...
Any further hint would be appreciated (like: the first 64kb of an *ogm video+audio+subs+... stream are vital, with mp3 the last 128bytes and the first [read byte7-10 here] bytes )
Thanks a million,
regards,
Koepi
raistlin2k
26th May 2002, 18:26
@Koepi
You're sure to keep always last 128bytes of each mp3? What for those mp3s containing no id3v1, but only id3v2.
I'm used to tag all my files only with id3v2 and delete all id3v1 if I've downloaded the file and not ripped it for myself.
WHY? (you will surely ask)
Well, just to be sure that there is no conflict (difference) between v1 & v2! Because some players prefer v1, some v2, so it may happen, that they show different info on the same file.
I know that 128 bytes is not so much, but it's no good to backup last 128 bytes, if they don't contain id3-tag, but only music.
Raist
Koepi
26th May 2002, 18:54
EDIT:
finally found a way to calculate the id3v2 tag length - stupid specs they made(c)Mastaa Yoda.
So I'm confident i get this baby rolling :)
Regards,
Koepi
Koepi
26th May 2002, 19:32
Well, well, first version running with mp3 support (still have to do something about non-existent id3 tags....). Btw., I _have_ to store something out of a file, else it would indicate it's stored as m2f1.
so gimme my 128bytes ;)
Now I just need final info on mcf and on avi.
Regards,
Koepi
Koepi
26th May 2002, 20:50
Ok, maybe someone can give me a helping hand with avi:
I found this link
http://www.rasnaimaging.com/people/lapus/avi.html
But here it is said that the index, fourcc etc. stuff is in the beginning of the file.
http://www.jmcgowan.com/avitech.html#Format
Still not too useful.
Any other good resources?
Regards,
Koepi
Tronic
26th May 2002, 21:36
For MCF, you must protect Main Header (in the beginning of file, size is at 0xA8). In ADDITION to that, you must protect all Small Elements which have protection-value below 0x0E (should actually be user-definable, but can be hardcoded).
The long piece of code, marked "MCF-dependant part" in the source, sorts and combines important stuff into few (typically 2-3) protected areas (protpos[] and protsize[], both on byte-precision).
There is no simple rule for n bytes from the beginning and m bytes from the end. Protected areas could be anywhere, the number of those may vary, etc.
Anyway, the MCF-CD code has handled all that correctly even before you started XCD ..
Koepi
26th May 2002, 21:43
Originally posted by Tronic
Anyway, the MCF-CD code has handled all that correctly even before you started XCD ..
I'm sad that you think of it this way. We try to support many formats with a nice CD structure and further enhancements to give some freedom on formats used. MCFCD sounds still very specific and misleading. Well, it's not too easy to implement MCF support into our scheme but it will be there in time (when MCF is ready).
Thanks for your help,
best regards,
Koepi
ChristianHJW
27th May 2002, 00:19
Originally posted by Koepi
I'm sad that you think of it this way. We try to support many formats with a nice CD structure and further enhancements to give some freedom on formats used. MCFCD sounds still very specific and misleading. ... well, there has been a nice conversation between avih and Tronic today on #mcf. Seems as if Tronic had some valid points about XCD, but in most other points he had a wrong impression about it. avih maybe wants to tell you a bit more about the outcome tomorrow ...
Koepi
27th May 2002, 07:16
This explains why he wrote me to "backup 2k from the start of every media file".
Well, kind of a summary, hm? ;)
koepi: no :)
to make a public summary.
the 1st 2K was an initial idea i had long time ago, i think it's even in the spec from 30-apr-2002 ((in the spec from 30-apr, last item of section 3.1)). i just forgot to discuss that when u, dext and myself talked few days ago, that's it. i just remembered in that since you were 'looking for 128B' with mp3 ;). that also reminded me the potential problems of the 'implicit mode 2 form 1' method (#segs=0).
what chris is talking about, is that late last night i talked to him and tronic, and we thought again about merging efforts with mcf-cd, to make a single strong standard. we didn't reach any conclusion, just points were raised about advantages and disadvantages of xcd/mcf-cd. surely, both are not 'perfect', and both can be made better. that's it.
no hidden meaning in anything ;)
in the meantime, the show goes on as planned ;)
cheers
avi.
ChristianHJW
27th May 2002, 09:15
Originally posted by avih what chris is talking about, is that late last night i talked to him and tronic, and we thought again about merging efforts with mcf-cd, to make a single strong standard. ... and in fact the more i think about it the more i am convinced there is absolutely no alternative to doing that. It doesnt make sense at all to have 2 different formats aiming for the same goal.
we didn't reach any conclusion, just points were raised about advantages and disadvantages of xcd/mcf-cd. surely, both are not 'perfect', and both can be made better. that's it. Well, what can you do with these crazy coders ;) . Instead of merging efforts they insist on their solution being the best and go for it, no matter if it makes sense or not. And if they talk to each other about it its getting more and more clear that the real differences are only marginal, so i wouldnt even be a big problem to make one solution. But, as always, nobody listening to the marketing people ... developers simply do what they want, and to make things even worse, you cant blame them for that because here they are not paid for their work :D !!
no hidden meaning in anything ;) Well, yes and no ! I know you all are doing this for fun and pleasure, but my general perception of Life is that with improved communication a lot of double work and failures could be avoided. So, i am indeed a little bit disappointed that there is no chance to find a common sense. But this is probably better discussed on IRC tonight, not here.
in the meantime, the show goes on as planned ;) To reach hardware manufacturers attention ( if this is ever going to happen ) both formats dont give themselves a benefit by going separate ways. There is the need for a MCF-CD to complete the MCF specs and make it attractive to both users and manufacturers, but i cant see any reason why there should be another technical solution for XCD and MCF-CD , or however we call the baby. Lets talk again tonight on #mcf .... looking forward to de_xt being back online, he has a very good way of bringing things together.
@chris ;)
amigo, no one is fighting, no one says we're NOT gonna merge, no one thinks only his solution is the best (that's true for me, and i think that's true for tronic as well).
all i said is that we didn't reach a conclusion LAST NIGHT! ;) that's it. as u can see, we still talk about that now and then. but i also don't think that we should STOP everything we do till we reach a conclusion. everyone is making progress, and if we merge, surely the time and experience spent/gained by each of us will be valuable and usable.
why do these creazy marketting ppl see everything in black and white?? ;)
best regards chris :)
avi
Chibi Jasmin
27th May 2002, 09:54
Using RIFF-CDXA test filter 6 for SVCD playback directly from the disc, I couldn't seek/jump in the file...is this a known issue?
BTW: Maybe make new threads for filter/mode2cdmaker and licensing/internal issues?
well jasmin, the non-seekable svcd is not a known issue. i use it and it seeks fine.
what mpeg2 decoders (=filters) do u have installed? i use it with freedvd, and it's working fine.
care to give us more details?
about a different thread... well, don't really know about that, it's a 'fluid' stuff, everyone replies on the same thread a question was asked. there are not too many xcd related threads atm... i think about 4 to the most, so it shouldn't be too hard following the happenings with this subject.
cheers
avi.
Chibi Jasmin
27th May 2002, 13:38
Well, with DVD2AVI it always works, with DirectShow based players I only got one short clip to work with seeking (some other short clips and long movies failed), but it could as well be badly muxed/encoded SVCDs, so don't give to much on this, I didn't make these SVCDs...
I have WinDVD4 DS-Filters for SVCD playback. Anything else you need to know? But well, don't spend too much time with this, maybe it's just screwed SVCDs..
Can anyone confirm SVCD playback with DShow and WinDVD4 Filters to work?
Koepi
27th May 2002, 13:47
Works like charme here with my test-SVCD (80 minutes ;) ) and the latest test6-filters.
Regards,
Koepi
Chibi Jasmin
27th May 2002, 13:52
You mean with WinDVD? Okay, then it's probably really screwed SVCDs...or does anyone have any other ideas or maybe the same problem?
I will try to make an SVCD myself and test, if I have time...
ChristianHJW
27th May 2002, 14:31
I do have so many MPEG2 decoder filters on my machine, i cant really tell if its the test6 filter doing the S-VCD trick for me ... but i recently installed it on my bros PC and he could play all my S-VCDs fine with avih/de_xt test6 filters, normal WMP 6.4 and the installed PowerDVD MPEG2 decoder filters ....
kagoru
27th May 2002, 22:28
Sorry if my question is stupid, but isn't it kind of senseless to burn an avi to a xcd since avi doesn't have ANY kind of error correction; that would mean that with every little scratch you automatically would lose a bit of video info. ain't that right? Does the error correction of ogg actually work for such a case? Anybody experienced?
TIA.
int 21h
27th May 2002, 22:43
Originally posted by kagoru
Sorry if my question is stupid, but isn't it kind of senseless to burn an avi to a xcd since avi doesn't have ANY kind of error correction; that would mean that with every little scratch you automatically would lose a bit of video info. ain't that right? Does the error correction of ogg actually work for such a case? Anybody experienced?
TIA.
Naughty Naughty, someone didn't read the whole thread before posting.
Yes, you must use a format that has builtin error correction (i.e. floating index, etc) in the file itself (i.e. ASF, OGM, MP4, etc). Currently the tools that are available do not backup the crucial parts of those files (because you still need a backup copy of the headers of the files), but that is soon to change.
kagoru
27th May 2002, 22:54
Thank you and sorry again. I just got confused because doom9 had a picture where he selected an .avi-file. In theory you could just burn any kind of data to a xcd, I suppose, even though it doesn't make sense right now.
Chibi Jasmin
28th May 2002, 14:04
Originally posted by Chibi Jasmin
Well, with DVD2AVI it always works, with DirectShow based players I only got one short clip to work with seeking (some other short clips and long movies failed), but it could as well be badly muxed/encoded SVCDs, so don't give to much on this, I didn't make these SVCDs...
I have WinDVD4 DS-Filters for SVCD playback. Anything else you need to know? But well, don't spend too much time with this, maybe it's just screwed SVCDs..
Can anyone confirm SVCD playback with DShow and WinDVD4 Filters to work?
I have created my own test-svcd and seeking and everything is fine now.
UPDATE: Remuxing the before non-working ones with BBMpeg made them work, too...
Koepi,
Are you still planning to release XCDBackupCreator since now it seems that there is a argument about this ogm extension.
r u gonna keep encoding? now that there's an argument about the ogg extension?? ;)
it will be released soon, don't worry. let us take care of few issues before.
cheers
avi
Koepi
28th May 2002, 22:34
I have to agree on avih here.
We're still discussing weather or not we're doing the backups "the right way" now.
Until now we agreed on releasing first tools soon and make them "version 0.1 beta" to indicate that we still are concerned.
But if we release them, we have to code backwards-compatible.
So we have to find a consense first about our minimum.
Sorry, can't give deeper insights yet.
Best regards,
Koepi
arty_sin
29th May 2002, 14:30
Originally posted by avih
Hi again.
attached is the latest RIFF/XDCA filter (test6).
Changelog:
----------
21-MAY-2002: test6:
- VCD and SVCD playback support added
- filter rewrite (for portability and future support for error protection)
- improved media detection
- file name changed from asyncflt.ax to xcdsrc.ax
- registry system modified to override ms VIDEO CD Source
(which doesn't read s/vcd correctly, and may introduce conflicts.
the uninstall script put back the original registry values)
SVCD playback may be a bit skippy since high bitrate is involved, and we didin't add buffering yet.
the filter DOESN'T support (=use) the backup files now. but the next version prob will.
this is a binary only release. the sources will be included again with the next release.
any feedback is welcome (especially regarding vcd/svcd).
enjoy
avi
Finally got this mode 2 stuff working with the 'test6' filters. Still had a bit of problem. Even after putting the full path in the .bat file for regsvr32 graphedit didn't show the new filter. So I used regdrop, at http://www.addisonsw.com, which got it in there. Also had to run the .bat file to get it all working. Some folks have had problems with CDRWIN. I found that unless the 'raw mode' check box is ticked you do indeed get problems. Goldenhawk says that the CD writer firmware attempts to put in error correction unless you do this which might explain things. It also says not all writers will use 'raw mode', which might explain a few more. I use LG GCE 8160B which also overburns well (recommended out of Tom's Hardware pages). Anyway I now have a 804,619KB avi on an autostart CDROM with codecs for sound and DivX included with their installers. All this on an 80 min CD (700 MB). Great stuff.:p
I'm back... wow, I guess I'll have to read a lot of posts to be up to date :)
@arty_sin: well seems there are some problems with the new install script in Win9x systems, probably due to REGSVR32.EXE not being in the default PATH (weird?). I guess I'll have to make separate install scripts for 9x ad NT class OSes :(
Please confirm me if changing the following lines from the install.bat script solves the problem (unregister it first just to be sure):
copy /y xcdsrc.ax %WINDIR%\SYSTEM32\xcdsrc.ax
regsvr32 %WINDIR%\SYSTEM32\xcdsrc.ax
for
copy /y xcdsrc.ax %WINDIR%\SYSTEM\xcdsrc.ax
%WINDIR%\SYSTEM\regsvr32.exe %WINDIR%\SYSTEM\xcdsrc.ax
Thanks for the note about the "RAW" switch in CDR-WIN, I don't need it with my burner, but I'll recommend to turn it on when burning in the readme.
@kagoru & int 21h: just to remember that AFAIK neither OGG, MP4 nor ASF have got error correction but error detection and/or error concealment. It's the same situation as with RIFF/CDXA (detection only), and the error concealment must be done by the codec/player itself. The problem with AVI is that this format is based in a chunk scheme, where each chunk has a "size" field, and getting a corrupt value here may prevent the rest of the file from being properly readed. The other formats are designed to deal with corrupt chunks without breaking the playing.
@Chibi: thanks for your nice tests with SVCD. ;)
@Nah: thanks a lot for your continued support making such a nice GUI supporting every new feature in mode2cdmaker. I may add this "-n" option in the next release so you don't have to make custom builds with every release. Seems this form2 extension is so important for you ;)
BTW if you have any suggestion regarding how subdirs could be implemented either from the command line or a list file, or any other thing, just tell me.
Koepi
1st June 2002, 16:57
Hm, a file with a list is easy top do:
just use fstream (ifstream / ofstream) to create/read the file, don't open it binary (it defaults to text) and then just used the built-in readline /writeline functions to paste the strings.
You could add a+ in front of a string to indicate it's a new directory.
or think about something clever like:
m2cdmfile 0.1
+this_is_one_dir
any_file_i_want.suffix
+this_is_two_dir
any_file_i_want.suffix
++this_is_two_and_one_dir
any_file_i_want.suffix
+++this_is_below_the_last_as_well_dir
any_file_i_want.suffix
+this_is_three_dir
any_file_i_want.suffix
so the numbber of + shows the directory-level.
Just a suggestion, don't know if it is this what you meant.
Regards,
Koepi
Chibi Jasmin
1st June 2002, 23:34
Originally posted by DeXT
@Chibi: thanks for your nice tests with SVCD. ;)
Thanx for helping in making this happen...I personally are only interested in the riff cdxa parser for svcds, because I prefer burning data-cds to be able to recover the full stream without flaws...but it all still is a great project, of course...
BTW: I guess, the SVCDs which did not work without remuxing (with bbmpeg) have been muxed with TMPGEnc at first...at least, I never got an SVCD I muxed with TMPGEnc seekable under DShow (PowerDVD etc. work), not even from hd.
Koepi
2nd June 2002, 00:46
@chibi jasmin:
My test-SVCD is encoded using tmpgenc and works flawless. I wouldn't blame it on the program...
But I didn't take the SVCD project settings but read the SVCD specs some times and fiddled around with the settings myself, this might be the difference.
Regards,
Koepi
i did a 35 mins svcd on a single cd, using tmpgenc, and burned with nero.
seeks and plays fine with test6 of the filter.
what filters do u use when playing svcd?
can u try to use graphedit and use the mpeg2 splitter and the fraunhofer audio and video filters (both from freedvd)? let us know your result.
cheers
avi
Sygma21
2nd June 2002, 09:25
Hi folks,
Just burned 790MB OGM/Xvid with 2x64kbps OGG in mode 2 and 2 Vobsub files in mode 1 .Works fine with WMP 6.4 and ZoomPlayer. Vobsub subtitled displayed perfectly
m2c 1.3 -l -a and riff test 6
Regards
@Koepi: yes this is more or less what I mean, simple & effective ways of entering new subdirectories either through the command line or an external list file.
The problem with list files is that they are more suitable for automated tools such as the GUI, where it should be generated automatically, since it's a pain if every user has to manually edit a list file everytime he is going to burn a XCD.
Your idea seems simple & smart, I think it's a good model for a list file. I will try to implement it this way, although I need to identify a Form2 file someway (perhaps adding "@" at the line start?).
About the command line I've received a modified build from a guy called Martin which adds subdirectories through the following syntax:
-f readme.txt pics\photo.jpg util\player.exe player.ini
This would take all files from the current dir (i.e. the mode2cdmaker dir) and put readme in root, photo.jpg in \pics and player.* in \util on the CD. The big disadvantage with this method is that it does not allow entering absolute paths (because any path before a file name is considered to be a subdir in the CD) and thus requires every input file being in the current directory. This also makes it unsuitable for a GUI usage. So I've suggested the following method:
-f readme.txt pics\ photo.jpg util\ player.exe player.ini
I.e. subdirs are entered just like any file but ending with a dir slash (pkzip also used the same method). This allows entering absolute paths for input filenames. I did not put the backslash at the beggining because this can be used to enter an absolute path in an input filename, too (i.e. \movie.avi means movie.avi in the root directory of the current drive).
The -d option won't be removed to maintain backward compatibility. This is just a simpler method of entering subdirs.
Martin's build also adds wildcard support, which is nice. I will add this to the next release, too.
Please tell me what do you think. And of course any other suggestion is welcomed. I just want to make it as user friendly as possible.
Koepi
2nd June 2002, 12:39
I think your suggestions are good.
For the structure-file I still think we should use signs which are forbidden for normal filesystem names, e.g. + and @ seem to be allowed in windows.
So signs like ' indicating mode2 file, ° indicating a directory...
Regards,
Koepi
arty_sin
2nd June 2002, 14:16
Originally posted by DeXT
@arty_sin: well seems there are some problems with the new install script in Win9x systems, probably due to REGSVR32.EXE not being in the default PATH (weird?). I guess I'll have to make separate install scripts for 9x ad NT class OSes :(
Please confirm me if changing the following lines from the install.bat script solves the problem (unregister it first just to be sure):
copy /y xcdsrc.ax %WINDIR%\SYSTEM32\xcdsrc.ax
regsvr32 %WINDIR%\SYSTEM32\xcdsrc.ax
for
copy /y xcdsrc.ax %WINDIR%\SYSTEM\xcdsrc.ax
%WINDIR%\SYSTEM\regsvr32.exe %WINDIR%\SYSTEM\xcdsrc.ax
Thanks for the note about the "RAW" switch in CDR-WIN, I don't need it with my burner, but I'll recommend to turn it on when burning in the readme.
[/B]
Thanks for getting back. You're right, I'm running Win98. I modified your .bat file modification to: -
copy /y xcdsrc.ax %WINDIR%\SYSTEM32\xcdsrc.ax
c:\windows\system\regsvr32 %WINDIR%\SYSTEM32\xcdsrc.ax
I did this because the location of the regsvr32 file is not on the path in my machine.
Still no joy. So then I did a search for regsvr32; and guess what; I had another one (as it happens in C:\Program Files\Mystik Media\AudioEdit Deluxe\BACKUP\regsvr32.exe). When I put THIS path in your bat file all worked fine. This could explain some other difficulties I've had registering filters. At some point I had obviously installed audio edit deluxe from Mystik media and the ****ing thing replaced my regsvr32 file. Now I'd already uninstalled it but the uninstall didn't roll back to the backup.
So then I checked file versions. The one that works is 5.00.1586.1, the one that DOES NOT work is 5.1.2600.0 (XPClient.010817-1148). Naughty naughty Mystik Media. I wrote to them at info@mystikmedia.com though I doubt it'll do anything.
But the point is, it's worth checking the version of the regsvr32.exe file...
Chibi Jasmin
2nd June 2002, 21:11
Originally posted by Koepi
@chibi jasmin:
My test-SVCD is encoded using tmpgenc and works flawless. I wouldn't blame it on the program...
But I didn't take the SVCD project settings but read the SVCD specs some times and fiddled around with the settings myself, this might be the difference.
Regards,
Koepi
I am not too much into encoding SVCDs... I meant simply muxing with TMPGEnc versus BBMPEG...
Hi again. I have just uploaded to my web a new filter release (test6b) which only adds new install scripts which are compatible with Win9x/Me (tested on Win98).
Hope this time everything works fine. Please test it and tell me if it works as expected.
http://webs.ono.com/de_xt
DeXT,
Is the wild card support in this version?
Well wildcards are being added to the mode2cdmaker tool, and not the filter as you can figure out :) This is just a filter release.
Doh!
Sorry, just get excited for a sec. :P
ccw23a
7th June 2002, 21:49
Originally posted by DeXT
Hi again. I have just uploaded to my web a new filter release (test6b) which only adds new install scripts which are compatible with Win9x/Me (tested on Win98).
http://webs.ono.com/de_xt
hi, this version is able to register without copying regsvr32.exe
however, i still face with problem with DS filter. here is my test:
1. setup new win98se partition, original (dx7), test mode2 mp3, sync problem.
2. installed riff6/6b filter, mode 2 mp3 runs perfect!
3. installed dx8/8.1, sync problem coming back!
4. reinstalled riff6/6b filter, still sync problem.
5. any suggestion? this is not my main concern anyway since XCD may not be compatible with current format + i'm going to update to winxp soon!
i only tested mp3 coz they are smaller file size and i know if it work, then the rest will work.
andy.
filters 6 and 6b are the same (and so is theoretically test 5 is you don't use vcd or svcd). the only change is the install script and some media detection. but if it installs ok and plays ok, then versions 5-6b are all the same.
regarding the skippy playback: it's probably due to lack of bufferring, but i didn't encounter such problem myself with mp3/ogg streams. can u pls give us some more info? like: 1. do u play from cd or daemon drive, 2: size of the clip. 3. detailed description of the problem (as much as u can). 4. use graphedit, and let us know what filters are used (insert filter -> dshow->RIFF/CDXA source. then select your media file, and then right click on the output pin and select 'render').
avi
I understand that skippy playback == our filter is not being used. This is what happens when you try to play a MP3 written in Form2 using DShow without having the CDXA filter installed.
I did my own tests under Win98 and found the following behaviour (all within the expected):
- played MP3 without our filter -- skippy
- installed test6b filter -- nice
- installed DX8.1 -- playback skippy again
- reinstalled filter -- nice again
DX8 setup restores the MS VCD Source key thus uninstalling our filter so the skippy playback is back, as expected. Reinstalling the filter puts our key instead so it returns to normal playback.
However, there is a situation where this does not happens and that is if you choose to use *.MP3 extension for Form2 files (instead of DAT). Since this extension is registered in the system with the default file source filter, our filter is not being chosen so the playback remains skippy. Please confirm if that was the case or not.
Hope this helps.
Koepi
8th June 2002, 13:48
I think it would be the best and easiest solution to not support custom extensions.
Just my oppinion.
Regards,
Koepi
Yes surely this would solve the problem, but I originally added this option because I wanted the tool to be usable with any custom format (MCD and XCD are two examples) which may or may not use the DAT extension for Form2 content. I know the situation has changed since then, XCD has chosen DAT as the default extension and MCD will probably merge with the former, but in any case I feel that limiting the tool may negatively affect its usability in future.
So currently I see putting the warning notice in the readme the best choice. People not following the suggestions in the readme will act at their own risk.
On the other side, I received a really nice mode2cdmaker GUI from ubik29, I'll put it on my homepage later today but I'm attaching it here too for your testing pleasure. I also received two NSIS installer/uninstaller scripts for the CDXA filter, one of them from this same guy and the other from ffortanet, I've sent them to avih so he can test and publish them.
Thanks to all the nice contributors to this project.
Emp3r0r
9th June 2002, 03:39
this GUI is much better IMO. It is exactly how I was about to program it. :D
ccw23a
9th June 2002, 09:38
thank a lot to avih and DeXT, win98se will now runs smoothly on mode2cd under dx8.1 only if in appropriate extension "DAT". my mistake b4 is usig mp3 extension. i have learnt my leason. sorry and thanks to all that help.
all the credit should go to dext, as he's responsible for all the registry and installation scripts ;)
cheers
Oletros
9th June 2002, 11:15
About the GUI, it doesn't makes the image, it launches de dos window and says Image created but actually it doesn't make nothing.
I don't know if could it be because the name of the moviw has spaces, but I deleted them and nothing happens.
any idea?
Thanks
Yes there is a bug in the way ubik29's GUI generates the command line, it should enclose any path or file name containing spaces between quotes, but it doesn't do so. This is needed for both the input files and the output image name/path.
As an example the GUI generates the following command line:
mode2cdmaker -m c:\my movies\movie file.avi -o d:\output image\image
While it should do the following:
mode2cdmaker -m "c:\my movies\movie file.avi" -o "d:\output image\image"
So to make it to work you have to add files that do not contain spaces neither in the name or the directory where they lay, and you have to click on the "..." button near "Save image to" to select an output image path/name without spaces, too. Once you do this it will work like a charm.
I'll have to report this to ubik29 so he can fix this small bug.
Oletros
9th June 2002, 14:18
Thanks for the answer DeXT, I tryed and everything worked fine.
Another suggestion for ubik29 for his gui, make view command copy and pastable.
arty_sin
10th June 2002, 13:57
Just one other thought. I normally prefer to use DivX Player 2.0 alpha to play my
DivX avis. As far as I can tell this doesn't use the DirectShow filters, but includes
the necessary decoders/filters in its' own code. Thus it cannot use the RIFF/CDXA
filters presented on this page. This is a pity because, at least on my system it
gives a better picture. This is particularly true in low light scenes, and is most
easily seen in the credits where bitrates are lower too. WMP, Sasami and BSPlayer
all show the same artefacts, and all seem to use DirectShow. What I see is
'contour lines' around the changes in shade, or 'paint runs' down from the titles,
and I don't get these effects with DivX Player 2.0 alpha. I am using a 1.33 gig
Athlon and NVIDIA GeForce2 GTS with 32 meg of ram. The system has nearly a gig
of RAM.
Any chance of a patch to the DivX Player :) Any ideas why it seems to perform better :)
DeXT
10th June 2002, 22:25
Ubik29 did a quick fix and sent to me a new GUI version which solves the paths-containing-spaces bug, I uploaded it to my page but for some stupid reason my ISP do not want to update its cache from several days ago. I found that writing the full adress including the html file gives the actual page so if you want to view the updated page please go to the following link:
http://webs.ono.com/de_xt/index.html
I also set up a mirror in Geocities since I'm tired of all these problems with my ISP, the page above contains a single frame pointing to the Geocities mirror. Hope this solves the problems once for all.
BTW I've attached the new GUI here too in case you have any troubles downloading it. Hope you like it.
@arty_sin: well unfortunately there's nothing we can do about this, only DirectShow-aware tools are compatible with the format right now and if these guys have chosen not to use DS (I guess they have a really good reason to do it this way) then this player cannot be used for XCD, sorry. Patching it would be too complicated and not worth the pain I'm afraid.
jurij
10th June 2002, 23:13
HEy you all can you keep us updated to the status of mode2cdbackup tool or whatever the program is called?
how much is left to release it?
Great, and thanx you all!
DeXT
11th June 2002, 01:28
Well the new features which will be ready for the next release are: subdir support for Form2 files (this needed a lot of changes), keep original Form2 file extension in the file name (like in Nah's GUI) and wildcards support. I've added/deleted some stuff while doing tests and before releasing I would like to re-add the alternate way of adding subdirectories (i.e. ending with a slash).
The last days I was not able to do a lot of work on the tool because I wanted to update my old project (cdirip/cdi2nero) to support DJ4 images, since I received some requests about it. But yesterday I finished it so today I've been working on this, did some tests, fixed bugs etc. I want to release a rock-solid tool because CD imaging is a major task and you don't want your files to be corrupted or somewhat when burning to the CD, right? This is why I only release fully tested code and not daily builds. This also gives some time to the GUI authors to keep in sync with the current version.
BTW I found out something, I was trying the wildcard stuff done by Martin (which was compiled using MSVC++) and it behaved strangely... then I found out it was due to the MinGW/GCC runtime which does all the wildcard expansion for me... so I just had to add a small piece of code to detect and discard directories, and it's working out of the box! So it's a pity I finally won't use Martin's code, but with GCC it's simply not needed (in fact I cannot use it unless I disable the wildcard expansion and I don't know how to do it).
TheXung
11th June 2002, 02:41
but what about the status of the backup tool? Right now it seems that XCD isn't useful for making any permanent burns because there isn't a way to backup the headers. The impression on this thread is that the tool is nearly finished for at least the ogg format, but it has been a couple weeks since we have heard anything. And if it is a matter of testing for compatibility, then releasing it would allow for the whole of the internet to be the testing playground.
If a status update is not possible, then is it at least possible to tell us how much the space the secure backup would take? whether it would be a fixed size or if it has to be a percentage of the filesize or number of frames? Basically I've found myself delaying dozens of rips because I don't know how much space afterwards I will have to work with.
Hi,
Cool, the new GUI is simple and quick. Mine is little complex ;)
Thanks DeXT to add the form2 file extension :)
And as TheXung said, hope that the header backup doesn't take too much space. I've bought new HDD to store my 800Mb movies :p
And,yeah, give these coders time to do the job ...
Koepi
11th June 2002, 08:22
Avih and DeXT should have my latest backupcreator version.
It works for ogg and shouldn't be problematic with future spec versions since the idea was to store the first 2kb or so of any stream in a backup header - from an ogg we store the first 64kb...
But it's not good to release this as ogg-only since this would be not nice to all the MCF people out there. And they made MCF backup really hard to understand - i still don't know how their code works, it's done somewhat recursive and made for another bakup system...
I still need to know what to backup from an avi since I didn't find too much useful info... nothing about indexes at the end of the file and so on, only some header stuff which is within the first few hundreds bytes (up to a few kbyte)...
Regards,
Koepi
avih
11th June 2002, 08:53
i have koepi's latest backup creator. however i'm too busy with rl problems atm. i don't forget xcd. and it WILL make progress. it's a promise. i'm doing my best to get back working on it again asap.
cheers
avi.
ChristianHJW
11th June 2002, 10:56
Originally posted by Koepi
But it's not good to release this as ogg-only since this would be not nice to all the MCF people out there. And they made MCF backup really hard to understand - i still don't know how their code works, it's done somewhat recursive and made for another bakup system...
koepi, thank you very much for your will to help MCF here, but i dont think you can wait with releasing your tool until MCF is ready. We just started a very interesting discussion with the people from mplayer dev team about a cooperation.
These guys are extremely skilled ( they reverse engineered Tobias' ogm fornat to be able to play it on Linux ) and we are getting a lot of precious input from them on MCF and how to make sure its best x-platform compatible ( there is a 1st alpha of mplayer running on MacOS ;) ), so it may take a little while longer until MCF hits the daylight.
Thanks again for your offer to wait with XCD release for Ogg, but i assume you just give it to the community as soon as you feel its ready for that. MCF will be used anyways if its better than other formats, and we are convinced it will be the best A/V format in the end.
BTW : mplayer people set up a new mailing list for mcf cooperation :
mcf-mplayer-coop@mplayerhq.hu
If you'd like to subscribe goto : http://mplayerhq.hu/mailman/listinfo/mcf-mplayer-coop
So, if we succeed in convincing the guys MCF is good, at least we have the Linux users on our side we hope :D !
TheXung
11th June 2002, 14:33
Ahh, so it only takes 64kb more space. Thanks a bunch.
raistlin2k
11th June 2002, 16:35
BTW, anybody knows something about tobias himself?
Because besides the XCD, OGM has a little problem, it can't use post-gain asserted by besweet or any other tool.
Does someone know if TObias will add this, and when?
Or is it possible for the guys of mplayer to do this for windows user and linux users as well?
Raist
jurij
11th June 2002, 18:21
@koepi:
quote "But it's not good to release this as ogg-only since this would be not nice to all the MCF people out there"
I believe that a beta is a beta so why do we all have to wait for the mcf part to be complete while many of us are ogg and do not care for the moment about mcf?
I don't think that it would be an offence for the mdf people, we wouldn't care if you could have released the mdf beta first!
And why you don't care for the avi people also then?
I just don't get the point why if the ogg part is complete to come out as ogg-beta! it is not such a big deal, we won't hurt mcf people feelings i think.
Don't you all agree with me???
Please everyone, reply :))
I am with ChristianHJW and jurij on this. Please give it to the community as soon as you feel its ready, and have another release when mcf is ready.
avih
11th June 2002, 20:07
releasing the backup creator without the filter that can read the backups (and the testing that everything's working as expected and no further modifications has to be made to the backup creator/filter) is not a wise decision imo. and since i was the one that wrote the core/parser filter code, and right now it's a bit hard for me to find the time to get back to it again, i'm the one that's causing the delay. sorry. as i said, i'm doing my best to get back working on the filter/core asap.
thanx for your understanding
avi
avih,
I jumped with the mob without looking at the whole situation. I apologize. Please take your time to work on the filter. You, Dext and Koepi have already done an amazing job. :)
The People's Elbow
12th June 2002, 02:52
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 :o
greetz, Elbow!
avih
12th June 2002, 08:06
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
12th June 2002, 11:53
THX for the quick reply and sorry for asking lame old questions ;)
... I'm like a noob in this thread :D
greetz, Elbow!
DeXT
12th June 2002, 15:37
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.
Kill the *.* Bring us the .Dat :D
Just my $$2c
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
12th June 2002, 19:48
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.
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....
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 :o /
avih
13th June 2002, 06:55
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
13th June 2002, 09:45
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
13th June 2002, 15:06
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.
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
13th June 2002, 16:52
@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
13th June 2002, 19:43
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
13th June 2002, 19:48
lol
no problem dude ;)
DeXT
20th June 2002, 00:47
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
@All devs. Keep up the good work!
you're making our lives more easy!
Thanks!
jurij
20th June 2002, 09:31
Hey :) good jobe Dext!!!!!
Does this mean we are close to the release of Koepi's Backup tool????
The Belgain
21st June 2002, 01:15
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.
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
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
23rd June 2002, 21:53
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
24th June 2002, 01:20
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
24th June 2002, 12:33
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
11th July 2002, 15:52
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
11th July 2002, 20:37
Thanks DeXT! I finally got it! That's the catch then for having 800 instead of 700 MB.
mustaneekeri
14th July 2002, 00:00
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
11th September 2002, 12:30
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
11th September 2002, 13:28
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
11th September 2002, 13:31
@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
12th September 2002, 00:20
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
12th September 2002, 19:04
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
12th September 2002, 21:58
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
12th September 2002, 22:37
what is the difference between 163 and 165?
Emp3r0r
12th September 2002, 22:45
nevermind, the 165 plays newer DVD-Multi, I just bought a 165 for 39 bucks shipped.
hazedlife
29th October 2003, 03:33
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!!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.