Roxio Toast Titanium 5 serial key or number

about the ".bin" wrapper, there's one thing that made me consider it: Creator/Type codes and, in particular, to have the image file pre-locked, once decoded. To my knowledge, on Mac, non-locked images aren't preserved in their purest state once mounted

The newest version of the Virtual CD/DVD Utility includes a handy Creator/Type restore dropper which turns a generic icon into a native Virtual CD/DVD Utility icon (double-click and it mounts the image without needing to launch the Utility separately). The Virtual Utility also mounts all images as locked by default, so mounted images do not get written to by that app, and there's no need to lock any image it mounts.

Toast will have no issue with mounting a generic Creator/Type code-less image, it will read from the data fork and determine it's OK as is. But manually locking the image may be required before mounting it.

Mac OS X will go by the ".iso" suffix file-name ending and give it to Disk Image Mounter to mount - but again, manually locking the image may be required before mounting it, if the downloader wants to preserve date and time stamps.

The Toast image in question appears to be unmodified since time of creation. Uploading it here as a raw .iso, preserves this, so it is fine IMO to upload it here as is for archiving. What someone does with it after this is up to them. I don't think most people downloading it will care one way or the other, will likely use it once to install and then toss it in the Trash. Those who do care about such things will probably (like myself) ensure all DL'd mountable archives are read-only, out of habit.

But if you feel it's more appropriate to include it in a .bin wrapper, then do so, I'll leave it up to you. I'm OK with whatever you decide, I just don't think it's necessary for this particular iso, but that's also just my opinion.

Re: Toast__Install_manicapital.com_.sit ( MB) vs. Toast__Install_manicapital.com_.bin ( MB)

Hi Jatoba. You made some good points there and the Virtual CD/DVD Utility is certainly the way to mount this .toast on classic Mac OS systems. The .img file is also a less useful addition as it doesn't preserve the original CD (and primarily, ISO archives of originals are always preferred here).

I made some "speed tests" of my own. On a i5 CPU box running a 32bit XP, it took 28 seconds to extract the .toast from the ".sit", using the commandline "manicapital.com" (The Unarchiver) to extract the image.

On a G4 1GHz eMac with standard IDE drive, it took 3 minutes 17 secs to complete the extraction.

FalconFour also made a good observation that very little space was obtained by compression of this particular image.

Regarding re-uploading the .toast renamed as .iso in a .bin wrapper:

By all means re-upload the .toast, renamed as ".iso" that will be great. However, don't bother uploading this one in a .bin wrapper as there is no point with this toast/iso file type, just the raw .iso will be fine. It will mount OK using the Virtual CD/DVD Utility and Mac OS X won't have a problem with it either.

Just to note; MacBinary (.bin) is not a compression algorithm, it only combines both forks of a classic Mac file into a single file as input and recombines the .bin file to it's respective forks in it's ouput. There is no advantage in using MacBinary on archives if they do not need Macintosh dual fork protection, such as .toast, .iso, .cdr, etc etc.

Also. There is very little point uploading a further compressed file if it only saves a couple of MB's over several 10's of MB's to GB's of data. Having it here as a raw Toast/ISO file is better, as it would mean there is no double-handling required by the downloader and a saving of disk space required to extract, i.e.; ".sit" (or .bin) file size plus extracted ".toast/.iso" file size, requires twice the disk space of a single .toast/.iso download.

@FalconFour
Hi. Welcome to MG, and it is appreciated that people want to improve things. That's always a good thing!

With that said, do know you do not need Toast to use a Toast image. In fact, to mount images, an incredibly lightweight, often-prefered option is Virtual CD/DVD-ROM Utility. You can also safely rename ".toast" files to ".iso" if desired. It's basically the same thing. Or just use Disk Copy, which you yourself used to create the new file.

Also, about SIT packages, do know that although they can compress, they don't necessarily have to, and most of the time these days, it is not used for compression, but for online and other forms of networked distribution of Mac files in a way that preserves resource forks. The fact it was MB "compressed" and MB decompressed is done to save you time by having less processing being necessary to decompress the file, by making it non-compressed in the first place, but just packaged. (Adjusted compression level.)

However! Since this is indeed only 1 single file, and not multiple files and/or a folder, it is true that SIT isn't necessary in this case, and just introduces unnecessary, insane overhead, so you can BinHex it the way you did, as long as it's ".bin" and not, say, ".hqx", which silently fails during download in some setups, apparently.

Nonetheless, I don't know what you have been doing wrong with your "7th gen i7" setup, but my SSD-equipped Mac mini G4 GHz with Mac OS decompressed the original "manicapital.com" file with StuffIt Expander in precisely only 2 minutes and 58 seconds. I used a stopwatch. It's safe to estimate your MHz G3 would have taken roughly 10 minutes, if also equipped with an SSD, which is nothing even remotely close to being as dramatic as you reported.

For comparison, I took your ".bin" download and decoded it using the exact same setup. It took exactly 9 seconds to get it decoded, which IS an astounding improvement of around 20x the speed, as I mentioned it would be, 2 paragraphs back.

However, neither Toast (which someone could be using an earlier version of to install this newer version) nor Virtual CD/DVD-ROM Utility are able to mount the image you created. And Virtual CD/DVD-ROM mounts images faster than Disk Copy. So that's also a point to consider. You also didn't need to compress the .img itself, because not only almost no space was saved, this introduces two problems:
- The time to mount the image unnecessarily slightly increases.
- If the resource fork is lost, the ".img" file becomes useless, which it otherwise wouldn't. It's slight, but this issue does make the image a bit less prone to survive over time, as people share the file down the line, especially because many people may think it's safe to store and share it without proper Mac encoding or compression, as ".img" is a common image format also outside the Mac world, as has tragically happened in the past. Not compressing aside, this can also be avoided by using ".iso" or ".toast" like the original upload.

TL;DR Both your and the original download could be improved by combining the best of both worlds: avoid ".img" and ".sit" for this version of Toast or, at the very least, don't compress the ".img" file.

I'm more than willing to reupload the original ".toast" file (perhaps renamed to ".iso" to avoid confusion) encoded as ".bin" instead of ".sit". Does anyone know if there's any problem that could be caused from using ".bin" instead of ".sit" in this case? I ask just to be more certain.

Though IMO, as we can see, this whole issue wasn't even much of an issue in the first place, so it seems blown out of proportion. Having left it as is seemed more than fine, with perhaps the addition of a link in the description to Virtual CD/DVD-ROM Utility for mounting ".toast" files, or include a statement saying ".toast" files can be mounted by Disk Copy just fine.

@spf
Classic Mac OS file's "Creator Type" and "File Type" codes are not stored in a file's resource fork but in the catalog tree of the HFS/HFS+ disk that the file is created on or moved to by the Finder. These don't get stored on a server running *nix or some NT/Win flavor (exceptions would be servers running NetaTalk and served read/write to a classic Mac OS).

Classic applications (and only the apps, not their files) store info about files that they use, in their own resource fork and must declare the OSType signatures of the files they intend to manage to the OS, so that the Finder knows what to do when a user double-clicks an icon. This is why periodically on a classic Mac system, you need to "Rebuild the Desktop Database Files" in order for the Finder to update its internal database (give "generic" icons their correct icons) and remove corrupted file signatures.

StuffIt ".sit" archives do not contain Macintosh resource forks, they are data only files and are safe to move and store "as is" onto servers over networks.

"Drag and Drop" is fine when used to extract StuffIt compatible archives with StuffIt Expander, including all of the above .sit downloads (+ .bin, .cpt, .hqx, etc;).

By all means launch an application and choose "Open" and navigate to where your files are located. However and fortunately for us; In a classic Mac OS, StuffIt Expander ignores any "Creator Type" and "File Type" signatures present or otherwise when opening files. It instead relies on reading the 1st few bytes of a file's data fork to tell it what to do (if it can or cannot extract an archive's content). This occurs whether you use the "Open file x", or the "Drag & Drop" methods - both work here.

Not all classic Mac applications are so forgiving, DiskDup+ and Compact Pro, for example require the "Creator Type" and "File Type" signatures to be "correct" before they will even attempt to open their own files ("Open file x", or the "Drag & Drop" methods - both fail) if their own OSTypes are not present for a file at a given location.

The classic Macintosh OS is the culprit at fault when receiving archives from non-classic Mac locations if it doesn't know what OSType a file should be. It "helpfully" assigns a ???? or TEXT or JPEG etc; OSType signature to its database for that file and file's location when the incoming file may be something entirely different. Hence "thestigmister's" error messages "Couldn't display 'file_manicapital.com' because a suitable graphics importer could not be found" - sounds very much like the OS has assigned Graphic Convertor (or some other bitmap editor's) OSTypes to incoming .sit files on his classic Mac system

I think the titles are self explanatory (and in chronological order).
The question is: What OS are you trying to run Toast on?
That will dictate what version you want to install and what version you can update to.

A lot depends on what OS you are running and if you are using a real machine or an emulator.
requires MacOS
requires MacOS -
requires MacOS -

An actual install of from CD requires OS or later.
However if you have a working folder you can use it in MacOS by installing Carbon Lib.
is also compatible with OSX through at least Tiger (x).

What updater you need depends on what version you are currently at and where are you trying to get to. As you can see there are about 10 different versions of Toast 5 ( - ) and three major releases (, and ). In addition some versions were available on CD while others were only upgrades (for example requires a valid installation of 5). I believe that Jam was originally an add on and not part of any install (hence the separate Jam installer). The downloads are roughly in chronological order and I had hoped the file names would be self-explanatory.

The first file is Toast with the updates needed to get you to
Downloads that have "CD" in the name are actual install CDs.
Files that just say "updater" are all the updates for that particular major version of Toast.
Files that just say "app" or "installer" are just the Application installer.

So the only full Install CD of Toast with Jam would be the CD.
But that requires So I've also included a pre-built folder.
Copy this folder to and install Carbon Lib and you can run Toast

So the questions are:
What OS are you running?
What platform?
What version of Toast do you want to run?

If you are running or above simply download the Install CD and the updaters and you're done.

A lot depends on what OS you are running and if you are using a real machine or an emulator.
requires MacOS
requires MacOS -
requires MacOS -

An actual install of from CD requires OS or later.
However if you have a working folder you can use it in MacOS by installing Carbon Lib.
is also compatible with OSX through at least Tiger (x).

What updater you need depends on what version you are currently at and where are you trying to get to. As you can see there are about 10 different versions of Toast 5 ( - ) and three major releases (, and ). In addition some versions were available on CD while others were only upgrades (for example requires a valid installation of 5). I believe that Jam was originally an add on and not part of any install (hence the separate Jam installer). The downloads are roughly in chronological order and I had hoped the file names would be self-explanatory.

The first file is Toast with the updates needed to get you to
Downloads that have "CD" in the name are actual install CDs.
Files that just say "updater" are all the updates for that particular major version of Toast.
Files that just say "app" or "installer" are just the Application installer.

So the only full Install CD of Toast with Jam would be the CD.
But that requires So I've also included a pre-built folder.
Copy this folder to and install Carbon Lib and you can run Toast

So the questions are:
What OS are you running?
What platform?
What version of Toast do you want to run?

If you are running or above simply download the Install CD and the updaters and you're done.

ok guys this is a mess.. re: the installers, there is a version, a version, and a version, none of these are labelled accurately. this download is too important to not be % solid.. we need all the updates posted here PROPERLY packaged as one download.. and we need the version of the installers to be labelled correctly. this whole download needs to be repackaged, renamed + reuploaded in a more organized fashion.
resulting in:

toastTitanium_v_manicapital.com
toastTitanium_v_manicapital.com
toastTitanium_v_manicapital.com
toastTitanium_v5_manicapital.com
toastTitanium_v_manicapital.com

can we not clean this up to be something similar to what ive outlined here?

as far as updates go there are many seperate updater files, some of the ones i have personally seen include:
Toast Titanium manicapital.com
Toast Titanium manicapital.com
Toast Titanium manicapital.com
Toast Titanium manicapital.com
Toast Titanium manicapital.com
Toast Titanium manicapital.com
Toast Titanium manicapital.com
Toast Titanium manicapital.com
Toast Titanium manicapital.com
this list is not % there could be a missing updater there somewhere but i have never seen 1 for or or

does anyone have the update? i need this one in particular.
all i can find is the ->
PLEASE NOTE AND READ CAREFULLY THE FOLLOWING::
the roxio site explicitly says the updates *ARE NOT CUMULITIVE*
that means they must be applied *IN ORDER* *SEQUENTIALLY* *ONE AFTER THE OTHER*
you cannot just get the latest update and install that
because the update does not contain the code from the lower updates
the same is to be assumed for the rest of their updates..
they are sequential.. not cumulutive..
these are not mac os "Combo" updaters.

the update is missing - we need to find it
it should be called "Toast Titanium updater"

xy, just a slight correction.

Toast will work with up to OS with all the extensions enabled. It will also allow use of the Disc Burner in the finder and the burner in iTunes.

It's when you go above c, up to v that you are required to disable the extensions, also Disc Burner.

And the good news with Toast v5 is that almost any CD / DVD burner will work. Can't guarantee it'll be bootable, but it may be. Last year I took the dual layer DVD+/-RW Optiarc A out of my Mac Pro - replaced one of them with a new Pioneer. Put the Optiarc (Sony / NEC) into my MDD G4, and tested it in all the OSX flavours I had installed, and in OS also. Worked a treat in all OS's. Submitted my report to xlr8yourmac Note, didn't try dual-layer disc burning in any OS, the discs are just too expensive.

This may be the best place to start loking for a compatible fdrive. Like xy hinted at, there are different levels of compatabolity, booting may be important, burning within the Apple included apps may be important (these may be referred to as the iApps, ie. iTunes, iDVD, iMovie), or just compatibility with Toast may be required. The more flexible you are, the more devices you will be able to use.

Just found my xlr8yourmac report, says I didn't test it in OS9. Maybe I didn't when I sent the report in, but I have since and it worked a treat in Toast.

Start your xlr8yourmac search here:
manicapital.com