MMB 0.5.0 now include both cdrdao & cdrecord

[Ross]

I have not tried to implement cdrecord into MissingMediaBurner because...

MMB uses the cdrdao engine, the best I can tell cdrecord is based on a modified cdrdao core. I see no advantage to the change.

The referece sites and emails I have received about cdrecord and overburn indicate putting no more than 700 meg of video on a 650 meg disk, this is not overburn. You can do that anyway, because multimedia is written in mode 2 without error checking.

Not all drive support overburn. But I have not found which do and which don't.

There is 1 thing I need help with however.
A second cdr on a system would use device "IOCompactDiscServices/2" or "IOCompactDiscServices /2" (with or without a space on the /2 ?). I have seen it written both way, I don't have a second drive to test it myself. Could someone give the correct answer.

If I am wrong on any of the above, please correct me.

[OmegaRedd1]

I dunno about a second device. But, I don't think cdrecord is "based" on cdrdao...the former is much more robust (i.e. more options for making images and burning them). Also, burning 700mb on a 650cdr or 800mb on a 700cdr is overburning if it's a data cd image. I have two issues with cdrdao/mmb:

1.) It has some sort of bug (either with the lastest versions of OSX or my burners) whereby cue sheets for DAO cannot be "sent" to the burner properly.*

2.) The bin/cue files that mmb creates **** with the resource forks on divx (and other?) files. (i.e. I make an image of an .avi and go to click on it to open QT and QT chokes because "data is missing")

Ross, I think your focus is on burning SVCDs(mode 2)...which is cool. But, I'm primarily concerned with burning divX avis and mov files which are over 700mb. And only cdrecord can create a working iso image of data files and then overburn it on my comp.

*cdrecord can't send a cue sheet to my burners either, if I put it in DAO mode. It's by only doing the bare bones and not sending a cue sheet that I can overburn successfully (sudo cdrecord -overburn dev="IOCompactDiscServices" ImageName). The point is that cdrecord can make self-contained iso images and overburn them without the need for a cue sheet. Whereas cdrdao *must* use a cue sheet.

I hope that was clear...I'm beat.

[Ross]

Thanks OmegaRedd1, for your persistence.
I was narrow minded in the direction of svcd.
With that said:

Please test MissingMediaBurner version 0.5.0
Both CDRECORD & CDRDAO have been intergrated
Generate ISO image
Rip audio disk to wav

The following is a clip from the ReadMe file:
"Included with this bundle are usage options for cdrdao, cdrecord, & mkisofs, as well as some notes and links to more info. Users are encouraged to review and test these options. The latest and full compiled versions of cdrdao and cdrecord (cdrtools) are contained in the Resource folder inside this app. I will welcome any working model improvements that can be implemented into this project. Also, If anyone wants to improve this ReadMe, that would be great."

Ross (RNC)

Download at:
homepage.mac.com/rnc

[OmegaRedd1]

Wow, Ross. I appreciate all the hard work you've been putting into this! MMB is fast becoming an inexpensive alternative to the Toast monopoly.

Yet, I have a feeling that there's still a long way to go. For starters, the overburn flag doesn't work when using cdrecord. But, that's just a minor fix. What could turn out to be more problematic are my continuing issues with disk images and QT movies. The ISO image that I create using the new option in MMB still corrupts my file (in this case, it's a QT .mov and QT says: "Couldn't open the file because a file's resource map was incorect.") If I create an image with the same file using either Toast or Apple's Disk Copy, I don't get the resource error and the movie opens fine. There's something with Apple file systems that unix tools can't quite emulate, methinks.

Overall, I can see you went out of your way to accomodate us data cd users. But, don't kill yourself trying to incorporate a billion options into MMB. I continue to think that full cdrecord support is the way to go. But, I'm not going to pretend I know as much as you.

I'd like to put out a request to all mac users with over-sized divx files to try the new MMB and confirm if it's only me with these stupid issues! Gah!

[Ross]

Let me start by saying:
Yes, I do have a day job, and it's not programming. I just hack around with this stuff for fun.

The more feedback (both good & bad) I get the more this app will evolve, and we all benifit.

The best I can tell, your reference to the overburn flag, was limited to the simulation only (I could be wrong). This is now fixed, you should be able to simulate an overburn.

The problem with the resouce fork, also was a quick fix. (at least I hope it's fixed) I just needed to read up more about mkisofs. This fix should have corrected the problem in both Gen ISO & Gen Cue/Bin.

A new version 0.5.1 has been uploaded at the same link.
It's still labled 0.5.0 so the bots at MacUpdate & VersionTracker don't see it till you guys get a chance to test it. (and give some feedback)

BTW, you don't have to pretend, you DO know as much as me.

[sterno]

There's something with Apple file systems that unix tools can't quite emulate, methinks.

Resource forks are native to Mac HFS, and no other system uses them. I think they're emulated with some kind of AppleDouble encoding if you use UFS in OS X, and there's some hack that allows the terminal to see the resource forks on HFS volumes. I don't know about current versions of QuickTime, but I know that older versions put important things in the resource fork so you had to explicitly tell your software to create a cross-platform QuickTime file (no resource fork) if you wanted to be able to play it on Windows machines.

The various packages that allow Macs and UNIX/Windows machines to share files use some method (like AppleDouble) to emulate the existence of a resource fork. mkisofs has the ability to process most of these formats to create a CD image with HFS or the Apple extensions to ISO9660. I don't need a CD burner on my Mac as long as I can mount my Linux machine as an AppleShare volume and use mkisofs to create a hybrid ISO9660/HFS/Joliet CD. mkisofs sure has come a long ways, I remember when it couldn't create anything but ISO9660....

At this point, I don't think either cdrecord or cdrdao can fully replace the other. Even though cdrecord added DAO support a few releases back cdrtools still looks like it's really a track-oriented package. And it's easier to copy CDs with cdrdao.

[Ross]

Hey sterno, thanks for the input. Seems like your in know with this stuff.

I added two prams to the mkisofs string,
--osx-double (Look for MacOS X AppleDouble Macintosh files)
--osx-hfs (Look for MacOS X HFS Macintosh files)

Each one seemed to image the resouce fork (when I mounted the image a QT movie was playable, where is wasn't before) I trust it won't hurt anything to have both in the string.

Now, how does that effect cross-platform compatiblity?
This is now only usable on Mac systems, unless we write as hybrid with two version of the movie? If that's the case, maybe you should us Toast.

[sterno]

I've been creating CD-ROMs on Linux for over 2 years now. The tools are essentially the same on every UNIX-like platform, the only things that really differ are the methods for accessing the burner (things like IOCompactDiscServices only exist on OS X, so I can't say anything on that).

I think the various options on where to get the resource information are additive, if you specify more it'll just look for more types of resource fork. You should specify "-hfs" to actually create it as a hybrid HFS disc, if you aren't already. It will create a hybrid disc that has both an ISO9660 filesystem and an HFS filesystem on it, with both pointing at the same set of files (with different names as needed) so the disc will be readable on other systems. Alternatively, use "-apple" instead of -hfs to use Apple's extensions to ISO9660, the end result should work just as well. I think I've found that a full HFS hybrid filesystem takes up a little bit more space on the CD, but the difference is only significant if you have a very large number of files and I suspect that HFS is a better choice in general.

You might want to try to set up a file for "-map" to map file extensions to file type/creator codes, but since you're really on a Mac you probably shouldn't need that. I use it when I burn a CD with stuff that's never been on the Mac and want to be able to double-click the files on my Powerbook.

Another nice touch on the Mac side might be to add the flag to try to keep icon positions the same on the CD as they were in the Finder, but I'm not sure how well (if at all) that works with OS X. You'll have to look through the documentation on that, I don't remember the option.

For better cross-platform compatibility, you probably also want "-r" (Rock Ridge), "-J" (Joliet), and/or "-T" (create a file translating 8.3 names to the real names for older systems). It may also be useful to enable ISO long filenames or level 2 compliance, the CD won't work right in DOS but it will on a number of other systems that don't support anything beyond ISO9660.

[schwinn]

I use MMBurner all the time and rarely use Toast any more. .0.5 has fixed the only issue I was having which was Burner and driver info not being saved. All in all a great app. There doesn't seem to be a way to burn a SVCD on a Mac without making a cue and bin file. Lucky for me they are quick and easy to make. Even the PC does a better job with SVCD's when they are bin/cue files. I just wanted to say a big thank you for this software! Schwinn

[OmegaRedd1]

By God, it works. Congrats to all; I'll try to test one of the new discs on a pc later in the week.

Cheers!