Mode2 CD Maker v1.5 out (w/GUI)

[DeXT]

Hi there guys. After long time, I finally released a new Mode2 CD Maker version (v1.5) this time with many improvements. The major ones are: Nested subdirectories support
Unlimited number of files per directory
Single track mode (to make a better use of space with many small Form2 files such as MP3 collections)
There are other small improvements such as: better use of available CD space, better memory management, non-single character commands, long file names by default, international support for subdirectory names, and many internal enhancements.

Of course the new Mode2 CD Maker GUI 1.5 from UbiK is also released, supporting all the new features! So you can now add entire subdirectory trees to the main window, keeping the original directory structure and not just the first level. This will be specially useful for players such as BSPlayer. I also suggested UbiK to re-add the old "Add Movies" button to ease addition of Form2 files (instead of having to manually switch them to Form2 once added).

Hope you find it useful. Feel free to post here any thoughts, suggestions or bug reports, if any (I hope not ;) ).

Get it here:

webs.ono.com/de_xt

DeXT

[iago]

Great! ;)

regards,
iago

[kxy]

¡Lo sentimos! este sitio está temporalmente inaccesible.

[Neo Neko]

Most excelent!

[kxy]

Sweet, page is back up, will test now.
:D

[Nocturnus]

Sounds great....:)

[jurij]

I just wanted to know if anything was happening from the backup tool side :)
I hope so....

[DeXT]

The problem is not the backup tool but the reader filter: avih don't want to have XCDs with certain backup format floating around and then discover something is missing when writting and testing a new XCD filter supporting them. So I'm afraid this will be released only when the new filter is out (I hope soon, though).

[TheXung]

I've noticed a lot of filters do not work properly with WMP9 without some reworking. mode2 filter can be included on this list. Does anyone know why this is the case?

[ookzDVD]

@DeXT,

I've got an error while creating image file,
Win2k SP3.

[atracus]

Originally posted by ookzDVD
@DeXT,

I've got an error while creating image file,
Win2k SP3.

same do I, both with Win2K SP2 and WinXP Sp1. it's a crash (a window pops up asking whether I want to send error details....)

but previous 1.4.x *works* on both systems.

[atx]

[Doom9]

@DeXt: please read your pms.

[int 21h]

Originally posted by TheXung
I've noticed a lot of filters do not work properly with WMP9 without some reworking. mode2 filter can be included on this list. Does anyone know why this is the case?

WMP9 seems to be very dependent on DirectX Media Objects (DMO) (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmplay/mmp_sdk/windowsmediaplayerrenderingplugins.asp), while previous versions used much more DirectShow.

If the filter isn't made with this in mind, many strange issues can occur (this is also the reason why many user interfaces no longer display in later versions of Media Player, which uses IPropertyPage for the settings)

[DeXT]

You are right guys, there was a *stupid* bug on Mode2CDMaker 1.5 which caused it to crash when no subdirectories were entered... you know, you make lots of tests with complex directory structures and miss the simplest one, a single file on root :(

The fixed release is 1.5a, hope it works fine now.

Thanks for your reports!

@int 21h: thank you very much for the useful information.

http://webs.ono.com/de_xt

DeXT

[alexnoe]

I've added capability to create CloneCD images file sets if single track is enabled. Not properly implemented yet (e.g. cannot create interleaved subchannel data which would be required to get an image file compatible to cdrecord -clone...), but seems to work, except of an invalid memory operation after closing the files :) I'll get rid of this.

http://www.alexander-noe.de/Mode2CDMaker/

[DeXT]

That's impresive!! I'll take a closer look at it ASAP. However I think you should temporally remove the buffer usage because this may be your source of problems (this is a primitive buffering implementation which may give strange behaviour if not used the right way).

BTW I was thinking in adding Nero image output support some day, too. It may be a good time to start working on it ;)

[alexnoe]

I think I've understood your buffer enough to use it properly ;) I hope :rolleyes:

If a separate subchannel file is created, the subchannel file is written without buffer usage. If no seperate subchannel file is created, the subchannel data immediately follows the corresponding mainchannel data in the img file (I've changed bin to img, because CloneCD requires img) and should thus work with your buffer.

FYI: the code to calculate the Q-Sub CRC is copied from cdrecord :)

Nero can read the cue sheet file, so NRG support is not really important...I've mainly done the CloneCD support because a few writers seem to create bad subchannel data and require to be fed with a RAW96 image :(

[s45i]

daemon tools does not support (and never will) .NRG images :(

i'm using successfully Nero (5.5.9.17) with .cue/bin images created with Mode2 Cd Maker 1.5a (Single track), sometimes with little overburning... more than 20 cd's, always fine...

creating .cue/bins with Mode2 CD Maker, testing with DaemonTools and burning with Nero is a nice path i think... even with a direct burning function i think i will still create .cue/bins for testing..

more.. after mounting the cue/bin in daemon tools any burning program could just "copy" from the virtual cd and burn a mode2 cd fine...

.nrg is not really needed i think... maybe an improved reader (with NSIS installer) it is :)

now (as a LiteOn owner) i fear about this subchannel issue, is it serious? what is stored in the subchannel data (of "xcd's"?)

(OT: This is my first post after a really long time of lurking and want to thank all Doom9 staff and users for all the precious information i gathered here. Thank you, *very* much!)

many thanks DeXT for your really useful tool! ;)

[alexnoe]

The subchannel data stores information about absolute time of sector and relative time of sector (to the beginning of the track). For Audio, it also stores ISRC and MCN codes.
Subchannel data is also used for seeking on the disc (that's why Twinsectors work).
So crap subchannel data alone suffice to render a CD useless.

Assuming that my code is not buggy, I recommend you to create CloneCD images.

Note that this DAO bug in LiteOns is hardly reproduceable...most people never encounter it. Seems that firmware 6S02 is affected, while 6S07/08 is not. It also seems to be media dependant (for which I have absolutely no explanation)

[celtic_druid]

Daemon-Tools does support NRG images, you just have to have nero's virtual drive installed first.

[DeXT]

@alexnoe:

I've been looking at your code, and you've done a really good work, specially when lowering to my ugly coding style so your additions fit on the existing code ;).

More seriously, I'm not friend of having to specify three options in order to be able to create the more common CCD/IMG/SUB image set. I like small, simple options (-ccd should be enough to make that behaviour). And is there a real necessity of creating a single raw96 image with sector data & p-w subchannel interleaved? Don't think much software is capable of reading this, however CCD image format is almost universal, and that also makes the code more complex. So I'd vote for a single option to create standard CloneCD images, without additional options.

BTW I did some tests with your CCD images and everything seems to be OK, it gives exactly the same results when compared with the BIN/CUE recorded ones. I'm currently on the process of trying to understand (again) the CCD format enough to be able to create multiple track CCD images. I tried it some time ago when I wrote cdirip but eventually I gave up due to the lack of information.

About the buffering, well you added a BufWriteFlush function call just before every BufWrite (for security reasons I guess), but this results in that no advantage is being taken from the buffer (since if resets to 0 after every write), so it's the same as not having any buffering at all... as I said it's a bit primitive as it's implemented now. But don't mind, I've improved it a bit and now there is no need to manually check the non-sequential writes and flush it manually (it now uses a BufWriteSeek function which does the check for us), so the code is much cleaner now. I also added a buffer to the SUB file, since it may raise over 30 MB on big images, so it's important having this buffered, too.

Here's my current WIP with your additions inside. Please feel free to make any comments, specially about the single CCD option vs. more options & more flexibility issue.

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

Thanks for your support!

DeXT

[alexnoe]

cdrecord can read a single RAW96 image with P-W interleaved (you need a key to unlock clone-writing). In the current implementation, it would suffice to implement the interleave-function and use it or not, according to the used command line options.

The clonecd file format is simple. You just write the q-subchannel data of the leadin into the ccd file, with one sector per "entry"-tag. All you need is explained in the MMC-4 standard.

Maybe you could add another option, such as "-ccd-fileset" which is equal to specifying all 3 options.

Your link is broken :(

About multitrack-CloneCD-images: All you need is to create a valid TOC, and also write the corresponding subchannel data (q-subchannel contains absolute and relative time stamps!).

[DeXT]

The link is not broken, it works with no problems, I've just tested it. It may have been due to a server overload.

About the user options, let's say 99% of users are going to generate standard CCD image sets, and maybe 1% is going to create a raw, interleaved image, for use with cdrecord. So just two options are more than enough, since no-one wants to create a SUB & IMG file without the CCD file, right?

-raw create RAW96 image (without cuesheet)
-ccd create CloneCD image set (ccd/img/sub)

I'll take a look at the MMC standard, but seems most fields don't change at all with different images (three Point=0xa0, 0xa1, 0xa2 entries, then one entry for every track w/Point=0x01, 0x02..., and finally three Point=0xb0, 0xc0, 0xc1 entries, most with fixed values).

Update: I already read the MMC4 standard and now I have a much more precise knowledge about how to write CCD images, thanks a lot for pointing it to me. I already modified mode2cdmaker to create valid multiple-track CCD (cuesheet) files, according to the real TOC, the only thing remaining is fixing the subchannel data so it points to the right track/index as well as relative/absolute addresses on pregaps etc. Once I have this finished I'll update the wip link above.

[DeXT]

The latest WIP (dated 12/26) has complete support for multiple-track CCD images, with right subchannel data according to CD-ROM specs found on MMC4 and ECMA-130 standards. The code is still a bit ugly (it uses global variables to pass tno/index/offset) but I'll have it cleaned for the 1.5.1 release.

I'm very pleased with it because this is the *BEST* way of burning a XCD without having to use DaemonTools or any other virtual image mounter, and gives a perfect copy without read errors on pregaps that may bring some recording software with less-than-perfect BIN/CUE support (such as Nero, Alcohol 120% etc). I may even leave CCD output the default one, along with the old CUE/TOC files for compatibility.

On my tests CloneCD gave the best results making a 100% perfect burn, while Alcohol 120% 1.3.5 inserts a something-weird pregap data, which doesn't give any reading problems, either. Single track mode works flawlessly for any of them, though.

Reports are welcomed.

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

[baddbill]

@ DeXT

Thanks for the great program. I have a couple of questions for you:

1. If I have been burning XCD's with Nero without any problems should I still try using CloneCD? What will I gain?

2. If I understand you web site, it looks like RV9 files won't work with XCD's. Is this right? Will their be a solution in the near future?

Thanks,
Bill

[DeXT]

1. If currently Nero works with no problems for you, you won't gain anything by using a CCD image. However, many people have been reporting burning/reading problems with some recording tools/burner combinations, myself included. This is why many of them have to use Daemon Tools in order to mount the BIN/CUE image and make a copy of it.

There is also a very common problem when reading back a multiple-track XCD in order to make a new copy: you may encounter read errors on pregaps, inserted by some recording tools, which doesn't affect playback at all, but it's an annoying thing also. All this should be gone with the use of a CCD image, because these contain much more precise data than a standard BIN/CUE.

2. The Mode2Real Plugin developed by wonderbread is intended to work with RV9, but since it was developed using the beta SDK, a recompilation is needed (and maybe some tweaking) in order to work with the final release. I really don't know if it will work since I have zero knowledge about Helix SDK and haven't tried to compile it either, but there is some chance that it will. If someone wants to download the latest SDK and try to compile it again, it would be welcomed.

[alexnoe]

Games which are protected with SafeDisc 2.80 contain pregap data which is not padded to zero. On any drives which support reading of pre-gap data, CloneCD backups won't work because CloneCD appearently does not copy the pre-gap data before the 1st track.
Since SD 2.80 loader just compares pre-gap data with "all zero", and fails to load if the result is "equal", Alcohol inserts some uninitialized crap.

No one could tell me any possible side effect of weird pregap data.

[baddbill]

Does anyone want to help out the RV9 community and try to make an xcd plugin that will work with RV9?

Alexnoe you seem knowledgeable. How difficult is this?

Any help would be appreciated.

Bill

[alexnoe]

How difficult is *what*? Copying pregap data or making such a plugin?

Since I have never ever done anything with DirectShow or any other plugin, I don't know how difficult the plugin part is, but reading Mode 2 Form 2 files is very simple.

AVI-Mux GUI includes support for reading such files (although there was a bug in it, and the currently uploaded source code could still contain that bug. The current exe files, as well as the next release incl. source code, will not have that bug any longer).
The corresponding code is put into a class and can easily be imported into other apps.

[baddbill]

Thanks for your response. I was talking about making a plugin. If I had any idea of what you are talking about I would try it. But, since I know nothing of programming I'll sit and wait for someone else to come up with a fix. Thanks for your info.

Bill

[alexnoe]

Any programmers of RV9 community are welcome to read this thread :D

[Koepi]

Well, I can't stand this RM9 stuff any more - everywhere you are asking to support it.


BUT it would be _SO_ easy: make a direct show filter for it, and you're done.

This propietary piece of crap isn't worth these many posts - the same like quicktime, and do you read anything about it? Quicktime is dead thanks due to propietary, closed containers.

Instead of bugging _us_, who code good stuff, ask evil Real to finally write a DSF of their codecs (believe me, it's a five minutes job for them).

Koepi

[ChristianHJW]

Originally posted by Koepi Well, I can't stand this RM9 stuff any more - everywhere you are asking to support it. This propietary piece of crap isn't worth these many posts - the same like quicktime, and do you read anything about it? Quicktime is dead thanks due to propietary, closed containers. Instead of bugging _us_, who code good stuff, ask evil Real to finally write a DSF of their codecs (believe me, it's a five minutes job for them). Koepi

I cant help it, but somehow i have to agree with koepi.
Guys, all these companies turning here advertising their stuff, releasing small parts of their proprietary implementations .... dont you see whats happening here ?
Why are all of them turning to Doom9, to post here 'in their free time' ?
Because from this place many kick-ass software developments were released in the last years, questioning their bussiness ideas. Not more and not less.

1. ON2 releasing VP3 as open source to Xiph as Theora, including the patents. How do you think the shareholders of ON2 did react to their money been given away for nothing ? Really for nothing ? Or is there a new form of bussiness idea behind that, like getting people used to the low profile stuff, so they are willingly to pay for high profile stuff ( i just hope the opensource community will kick their asses and make Theora better than VP5 :D !! )

2. Real giving away Helix, so everybody can implement the Real container and streaming server into their apps, while the codecs itself stay closed and Karl is waiting for about 3 weeks fro a reply from his management if a Real VfW or Dshow codec was allowed by the Helix licensing or not ? Dont you smell the idea behind that ?

3. Amir from M$ telling us how wonderful WMV9 is ( and he is the only one BTW where i am convinced he really comes here in his free time and was not sent by his company ), while in reality you are bound to using WMA for audio, WMV as container and Windows Media Encoder for encoding ... freedom of choice ?? WMV9 with Vorbis in OGM ? Not in this century, i swear !

Why all of this ??

Because of commercial interests of all this companies !!

Dont misunderstand me, i am a bussiness man myself ( although in a completely different area, industry automation ), and there is nothing wrong about commercial interests IMHO.

But please, please, guys, read between the lines ! Dont be stupid !

XviD belongs to us, and its getting better and better all the time ! While hardware support ( and thats what we want for our rips ) for WMV9 is likely to come, its highly unlikely for RV9 and VP5 ..... but its here today for MPEG4 !! You can buy these stadnalone players today, they are here, and working ( even with crappy AVI ) ! The patent situation and the fact that binaries may not easily be distributed from the official site may not be completely satisfactory, but for sure we will always find a way around that :D !

Think about that ... and support XviD, instead of asking the devs here to invest their precious time into making a RV9 Dshow filter !

Regards from the real ( ;) ) opensource community

Christian

BTW : This post was not ment to advertise the open standard container project i am working on, as we already have 2 open standard containers to use ...

[Koepi]

Heh ;)

Btw., I lied about quicktime: the propietary, patented, closed container format still lives in MPEG4. (MP4 file format of course.)

But what I meant with quicktime-is-dead is: nobody uses sörensen codec, only some companies for trailers. Quicktime's mpeg4 video codec sucks. And so forth.

I hope you get the idea.

[baddbill]

Wow!

[baddbill]

Wow! I didn't mean to get everyone so excited. All I am asking for is if anyone who is interested in RV9, and has the ability, is interested in making a plugin. This is the new A/V formats forum, right? If you guys don't like what you read here then don't read here. Pretty simple huh?

It seams pretty ironic that the moderator of this forum would have a problem with someone using the forum to discuss new a/v formats. Maybe there is a conflict of interest here? It doesn't seam very professional for a forum moderator to get mad at someone bacause they are discussing a certain codec too much.

I have no allegiance to a certain codec. I have used Gknot to make many encodes over the last year or so. After reading doom9's latest comparison of different codec's I did just what he recommended his readers to do. Which is to try a couple of encodes with RV9 and see what they think. I did that and concluded exactly what he did. That RV9 is the most natural looking codec.

Sorry to get everyone so stressed out but if you're not interested in "new A/V formats" then don't read here.

Bill

[jcsston]

I've created a few Mode2 cd's. The strange thing is my burner a Lite-on LTR-16102B says they are audio cd's and will not play them. But my older Pioneer 24x slot cd-rom will read them.

[TheXung]

www.doom9.org has the potential to have an outstanding effect on the commercial world of video compression. Rippers all over the world turn to this website to learn how to rip. And while ripping groups may dis this place sometimes, it's also probably where they all learned to rip. People listen to him. People read his guides.

What does this actually effect? Well, people in many countries only buy/download ripped movies, never the actual DVD. What is missing is the wide hardware support to play these on a set top box. Once that is in, we're basically looking at the next S/VCD format. As anyone can see, this is where the masses will be. This is where the money can be made. People won't care about buying a set top box that plays WM9 or Real, just mpeg4 in an avi or ogm container. XCD can also be on this list of debate.


Remember there are too kinds of standards, one that is declared by a group and one that the public has come to accept. Companies are always trying to sqeeze their way in by the second method. And they have turned to using doom9.org as their lackey. Wide acceptance of some of these formats is the result of how good the tools are at supporting them, which is the result of programmers' work here. Programmers should choose carefully whose side they want to support because it can feel really bad to look back after a few years and realize you did a companies' dogwork and they're making millions off the wide acceptance you help to build up.

[alexnoe]

@jcsston: Do you burn with CloneCD or Nero? Single track or multitrack?
If you burned multitrack with clonecd, then please post the entire ccd file :)

[Koepi]

Good morning badbill,

welcome to the list of nearly-suspended users.

If you'd read my post again you wouldn't even dare to insult me that badly. I wrote that it's real's job to write that "plugin" called DSF (directshow filter for the uninformed people).

It's a bit too much to ask us for, ask them, they want to make money, they should supply the support as they're selling their stuff - we all are spare-time coders here. Why should we code for free[tm] to let them get even more bucks?

I hope you finally understand this. But I doubt it seriously.

Koepi

[Koepi]

@DeXt:

Did i send you the backup creator sources last year? Maybe we should think about adding it to mode2cdmaker GUI and support (at least) OGM for now with it. OGM specs are fine and not suspect to change, as well as mp3 id3|v2 tags are.

As for avi, I vote for storing the first 64kb and the last 64kb for "testing purposes". Adding this to the dshow parser shouldn't be too bad as it gets stored in the backup files which "regions" of the streams are backed up. So if we decide to store the last 128kb, we can simply change it, the old XCDs stay playable (maybe with worse error correction, but still playable).

I think this would help the development.

Just my 2 cents,
Koepi

[alexnoe]

@badbill: This is the place to discuss new A/V formats. But this is certainly not the place to discuss anything someone gains money with!

[MaTTeR]

@jcsston

I have that exact same Lite-On drive in my HTPC, one of the more reliable drives I've used. Lite-On updates the firmware for these drives fairly often so you might make sure your running the latest version. I usually burn the bin file using Nero 5.5.10.x in DAO mode. Good luck.

[jcsston]

Originally posted by alexnoe
@jcsston: Do you burn with CloneCD or Nero? Single track or multitrack?
If you burned multitrack with clonecd, then please post the entire ccd file :)
Thanks :D
Burning it with Nero with single track made my cd burner work correctly.

[baddbill]

Hi Koepi, I understand your viewpoint but don't share it. I don't view RV9 as the evil empire. I see them as a company that has developed a good product and wants to make some money from it. I don't see anything wrong with this.

I took offense to your post because of its tone and direct nature. I have no problem with you having a different opinion.

Thanks,
Bill

[alexnoe]

I took offense to your post because of its tone and direct nature.So you prefer long sentences with lots of "i'm afraid that it might be possible that I do not share your opinion..."? :confused:

If you feel insulted because of a "direct tone", then please visit forums with only british people :sly: , and avoid any place where germans turn up :D
I personally consider a direct tone more effective, and reduces the chance that the addressed person doesn't get the contents.

You say yourself that RV9 can be considered a company. In this very moment, doom9 is the wrong place to search for help.

[ChristianHJW]

Originally posted by alexnoe If you feel insulted because of a "direct tone", then please visit forums with only british people :sly: , and avoid any place where germans turn up :D

LOL !!! ... LMAO .... true, German way of saying things is not 100% compatible with the very subtle communication details to be found in anglophonic conversation ... ;) ...

[MaTTeR]

Originally posted by ChristianHJW
LOL !!! ... LMAO .... true, German way of saying things is not 100% compatible with the very subtle communication details to be found in anglophonic conversation ... ;) ... LMAO...I work for a German company and good friends with a few Germans on this board. I couldn't have said it any better:D :D

[Beave]

Will this new CCD Image change the behaviour of cdrdao? I burned over 100 OGM/XCDs with it by now with the liteon 24x burner and overburning. They all work great.

BTW, I have trouble downloading wip as well.

Is there a workaround for copying the XCDs faster? If I do a direct copy it takes around 11 minutes for one CD to copy. I have to turn the writer to 8x to not use the bufferunderrun protection. It's great for playback though, since it's so quiet.

Thanks for these wonderful tools. I saved 10 GB on CD by now.

[DeXT]

Koepi said:Did i send you the backup creator sources last year? Maybe we should think about adding it to mode2cdmaker GUI and support (at least) OGM for now with it. OGM specs are fine and not suspect to change, as well as mp3 id3|v2 tags are.Yes I got a copy of your sources, and the last ones are published on the latest XCD filter "alpha" sources package, available at my homepage. Getting support for automatic backup generation on the GUI would be great of course, but the decision to implement it is subject to UbiK's criteria, since he is the GUI developer. I can just suggest it to him.
As for avi, I vote for storing the first 64kb and the last 64kb for "testing purposes". Adding this to the dshow parser shouldn't be too bad as it gets stored in the backup files which "regions" of the streams are backed up. So if we decide to store the last 128kb, we can simply change it, the old XCDs stay playable (maybe with worse error correction, but still playable).I'm with you here, storing the first and last 64 KB of every file would be enough protection for most common formats, which maintains the old header-and-tail design (Matroska is an exception here of course ;) ).

Beave said:Will this new CCD Image change the behaviour of cdrdao? I burned over 100 OGM/XCDs with it by now with the liteon 24x burner and overburning. They all work great.CCD support does not change behaviour for cdrdao or any other currently supported format, because no changes are made to the existing BIN/CUE/TOC files, other than the IMG extension instead of BIN (which is reflected on the CUE/TOC files of course). CCD support just adds two extra files, namely CCD & SUB. BTW I'm seriously thinking in generating these by default, so no extra options would be needed, and will work with the current GUI with no changes.
BTW, I have trouble downloading wip as well.I know it, seems my ISP is having serious trouble with their WWW server, it's constantly down. You can get it from this mirror too:

http://es.geocities.com/dextstuff/wip.zip
Is there a workaround for copying the XCDs faster? If I do a direct copy it takes around 11 minutes for one CD to copy. I have to turn the writer to 8x to not use the bufferunderrun protection. It's great for playback though, since it's so quiet. AFAIK there is no workaround since this is a hardware default behaviour when reading Mode2/Form2 tracks, the drive slows down in order to provide a sustained transfer rate suitable for VCD/SVCD.
Thanks for these wonderful tools. I saved 10 GB on CD by now.You are welcomed ;)

PS: mirror of my homepage located here:

http://es.geocities.com/dextstuff/