Re: Roxio Toast Titanium 11 Keygen Mac
Ludmila Hargett
Those are sound arguments. I guess there's also the fact locked images are more bothersome to mount (because of the extra dialog box) for the general user. And if people want to lock the file after downloading, they still can.
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.
@MTT Will do. But first, 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, because it accepts write operations to them, and there are things the Mac system writes to the image by default in that case. Of course, this is only relevant from a "historical preservation" perspective, and that too only if we can assume the ".toast" file in question has never been mounted that way before.
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 "unar.exe" (The Unarchiver) to extract the image.
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.
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 100MB "compressed" and 101MB 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 1.5GHz with Mac OS 9.2.2 decompressed the original ".toast.sit" file with StuffIt Expander 7.0.3 in precisely only 2 minutes and 58 seconds. I used a stopwatch. It's safe to estimate your 500 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.
So, the package here for 5.21 is really, really bad. It's a Toast image wrapped in a SIT packed so tightly my 7th gen i7 struggled to decompress it - it was going to take an eternity on my 500MHz G3. And it only decompressed from 100mb to 101mb. Waste of every conceivable thing! Then, it's a Toast image, which needs Toast, and it is Toast, so you need Toast to install Toast.
Screw that noise. I'm uploading a repackaged version - a Disk Image compressed copy created with Mac OS 9.2.2, wrapped in a MacBinary II package from Stuffit. Worked rather hard to make sure this all worked out.
I'm having to ignore the warning about uploading new versions, because I'm pretty sure I'm going to forget and/or not care if I have to bother that hard... seems like a clear cut case of better packaging. Delete mine or the other if you want to deduplicate.
@spf1954:
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.
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.
b1e95dc632