Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
How do I create an .iso image?
- Thread starter lamina
- Start date
- Sort by reaction score
Why Delete Helpful Info?
Hello everybody
! I don't want to sound negative or anything, but I have been posting original answers to this thread that answer questions asked in this thread that nobody else in this thread has answered (including the original question that started this thread
). Even if this thread is a little old, its important to leave questions properly answered for people scouring the Inter Webs for knowledge - we've all been there!
Hello everybody
! I don't want to sound negative or anything, but I have been posting original answers to this thread that answer questions asked in this thread that nobody else in this thread has answered (including the original question that started this thread
, yes, Disk Utility CAN make an iso compatible with everybody from a CD. You rename it from *.cdr to *.iso if you feel the need, it already is an iso, just "misnamed." Dimwhit seemed to be saying something similar, but I don't think he was using Disk Utility because he had an original file extention of *.img instead of *.cdr.), and people chose to delete my posts.
I understand the terms I have agreed to, including that editors of Mac Rumors may delete my post for any reason, but I wonder why people are choosing to delete my posts given that I am answering questions that no one else is. This is approximately the fourth time I've posted to this thread, and every time, my posts get deleted. I will try again, and have read the whole thread again (I have several times), and did catch something important I missed before: some people mean "building" an iso (as in taking folder contents and building a CD image from that, which involves making the CD filesystem, etc.), and some people mean "imaging" when they say they are "making" an iso (which is a dump of a CD). It's important to know which you are trying to accomplish (or both!
). Even if this thread is a little old, its important to leave questions properly answered for people scouring the Inter Webs for knowledge - we've all been there!Answers & Reasons
Hey everybody! This thread is talking about two different things: building images and imaging.
Imaging (at least the kind of imaging in this thread's context) is dumping the raw contents of a disc into a file. This is VERY different than copying only the files and folders off a CD. There is much more to a CD than just files and folders, such as one or more filesystems, a volume label for each filesystem, several other "labels" (one is a label stating the program used to burn the disc), sometimes boot information, etc.
Building an image is the process of selecting files, folders, ior boot info to be thrown into a magical machine (hdiutils, in this case) that weaves them into a new filesystem/ structure and outputs a CD image that can then be burned to a disc (or mounted). Notice this is a fresh new making of the entire CD structure - you get to pick the filesystem and everything.
The original question is excitingly vague (it doubles the fun!) because we don't know if Lamina wants to build an iso, or image a CD, yielding an iso:
Robbieduncan did an absolutely exquisite job of answering the building half:
...but no one answered if a CD can be *.iso'd IN DISK UTITLITY. Yes, tgage went on to say it could be done with dd (don't get me wrong, it's GREAT info!), but the original question was if it could be done in Disk Utility. Yes, it can be done in Disk Utility. Just chose DVD/CD master, let it go, then rename the outputted file from *.cdr to *.iso. The file is already an iso file to begin with (we didn't do any magical converting by renaming it), it just was "misnamed." In fact, the box with the status bar as it is being imaged shows the text "APPLE_ISO." This *.iso file will be compatible with anything that takes iso files. The lesson is that a dump of a disc is always a dump of a disc, no matter what it has been named. A raw dump is not capable of being incompatible with anything because it is just raw. Dimwhit can at least somewhat back me up on that:
I even personally tested all these things to make sure what I am saying is correct. I installed VirtualBox into Mac OS. I have an iso image of a bootable Windows 98 install CD. VirtualBox boots this iso image just fine. I burned this iso image to a physical CD. I imaged this physcial CD in Mac OS with Disk Utility with the DVD/CD master option picked, so it gave me a *.cdr image file. I got the md5 hash of both the ORIGINAL iso file and the *.cdr made from the CD made from the original. Their hashes matched, therefore they were IDENTICAL. Here's the syntax for finding the md5 hash of any file in Mac OS (or Linux) through terminal:
I also experimented with the hdiutils makehybrid method from Robbieduncan, but out of its intended context just to gain some info. I renamed my Windows 98 install CD iso on my desktop to Master.cdr, and after cd'ing to my desktop (changing directory of terminal) I ran:
Oddly, the input is placed after the output here. Commandline utilities are almost ALWAYS input then output, in fact, this is the first I've seen contrary to that. I was yielded a re-made image assembled by hdiutils named "Master.iso". The hashes DID NOT MATCH. This means the files are NOT identical. To be sure, I tried to boot the re-make with VirtualBox. Not bootable. Tried to boot the original; it booted.
Does this mean Robbieduncan's method is bad? Of course not! His method is intended for building images from scratch (using source files and folders), not making images of existing CDs.
Note that dd adds extra zeros to the end of image files it makes of CDs. Most programs (including Disk Utility) do not add extra zeros. This will make the hash of a dd-made iso not match the hash of a Disk-Utility-made iso, even if you use the same physical CD to do both. I have tested this myself. It adds zeros to the file until the file size in bytes is a "nicer" looking number. Dd-made isos are still good.
And tgage, although dd can dump an audio CD to an image file, it is a mistake to name such a dump with the file extension "iso", even though nothing stops you from doing it. The act of naming a file with the extension "iso" is saying to every person who looks at that file that "this file is a CD image with an ISO 9660 compatible filesystem and is comprised of only one track." That's what people educated in this area expect when they see a file named with that file extension (not that you're not educated, because obviously you are). It's a naming convention standard, and it is the definition of an iso image file. The iso image standard only allows for one track. Audio CDs not only usually have more than one track, none of these tracks have a filesystem. Each track is raw digital audio data. An audio CD is pretty much a digital record, where the player just fires its laser at the disc, lets it spin, and the data coming out is directly interpreted as sound, without the need of a driver to understand a filesystem (as it would need if the audio data was instead a sound file in the ISO 9660 filesystem, or even the HFS+ for that matter), and it also does not need the ability to parse the file after finding the file with such a driver. There is still structure, but not as intense as say a thumb drive or regular CD/DVD.
So Calatis, it appears that you used an iso burning program to burn the dump you made of an audio CD to a physical CD. I imagine that you (no offense) misnamed the dump with the *.iso extension, then told an iso burning program to burn this non-iso to a CD. Iso burning programs are geared for burning isos, at least while they are burning one to a disc. There are two burning modes, TAO and DAO. They are Track at Once and Disc at Once. Disc at Once allows for more direct control of the hardware than Track at Once allows. Audio CDs have a very strange structure (no filesystem, multiple tracks, etc.) and therefore need the more direct hardware access offered by DAO to be burned (can't make this wierd structure with the limits of TAO). Actual isos (no offense, tgage) can be burned with just the TAO method (because they are "normal," have a filesystem, have only one track, etc.). Therefore, it isn't unreasonable to suppose some iso burning programs only use TAO because that is all they need. When you forced an audio dump to be burned in TAO mode, it couldn't burn right because TAO can't burn some of the stuff in that dump (like song titles and all that stuff you said that went away). TAO also automatically inserted those 2-second gaps. Since it thought it was burning an iso (which only have one track), it is no wonder your audio CD came out to be one long track with 2-second pauses. Check this site out for more details.
Also Calatis, note that Mac's iso mounter is not a true CD emulator. It does not actually emulate hardware at all. It is a pseudo-device. Pseudo-devices need a filesystem in the image file they are mounting to work. Pseudo-devices are the doing of the driver itself, and the whole system knows that the pseudo-device is not a real CD. It doesn't even try to make it look like hardware at all. A true CD emulator makes it impossible to know if the emulated CD reader is real or not. Because of the pseudo-device's need of a filesystem to mount an image file, and since the audio dump has no filesystem (made from disc with no filesystem), Mac could not mount the audio CD image. In contrast, Magic Disc, a true CD emulator for Windows, can mount audio disc images properly, and you can play the music right off the emulated drive as if it were a real audio CD.
Hey everybody! This thread is talking about two different things: building images and imaging.
Imaging (at least the kind of imaging in this thread's context) is dumping the raw contents of a disc into a file. This is VERY different than copying only the files and folders off a CD. There is much more to a CD than just files and folders, such as one or more filesystems, a volume label for each filesystem, several other "labels" (one is a label stating the program used to burn the disc), sometimes boot information, etc.
Building an image is the process of selecting files, folders, ior boot info to be thrown into a magical machine (hdiutils, in this case) that weaves them into a new filesystem/ structure and outputs a CD image that can then be burned to a disc (or mounted). Notice this is a fresh new making of the entire CD structure - you get to pick the filesystem and everything.
The original question is excitingly vague (it doubles the fun!) because we don't know if Lamina wants to build an iso, or image a CD, yielding an iso:
So we ought to answer for both possibilities...whoopie!
Robbieduncan did an absolutely exquisite job of answering the building half:
...but no one answered if a CD can be *.iso'd IN DISK UTITLITY. Yes, tgage went on to say it could be done with dd (don't get me wrong, it's GREAT info!), but the original question was if it could be done in Disk Utility. Yes, it can be done in Disk Utility. Just chose DVD/CD master, let it go, then rename the outputted file from *.cdr to *.iso. The file is already an iso file to begin with (we didn't do any magical converting by renaming it), it just was "misnamed." In fact, the box with the status bar as it is being imaged shows the text "APPLE_ISO." This *.iso file will be compatible with anything that takes iso files. The lesson is that a dump of a disc is always a dump of a disc, no matter what it has been named. A raw dump is not capable of being incompatible with anything because it is just raw. Dimwhit can at least somewhat back me up on that:
This is why halfl1fe was able to boot off the *.cdr (it IS an iso, at least when imaged from a CD), which contained boot info, as it is an accurate replication of the original disc.
He could not, however, boot off the *.iso that was made with hdiutils that took (probably only, or close to it) the files contained in the *.cdr, and re-wove them into a new filesystem/ structure without boot info. Thus this re-make is not identical to the original disc, and is not bootable because it has no boot info. The boot info is NOT a file, it is just a bunch of 1s and 0s chillin' out in a special spot on the disc outside any partition or filesystem. I know that with mkisofs, there is a switch you can specify to tell it to use a boot image file, and it will suck boot information into the tapestry as it weaves away a new image file from scratch. There probably exists a "use this boot image" switch for hdiutils.
I even personally tested all these things to make sure what I am saying is correct. I installed VirtualBox into Mac OS. I have an iso image of a bootable Windows 98 install CD. VirtualBox boots this iso image just fine. I burned this iso image to a physical CD. I imaged this physcial CD in Mac OS with Disk Utility with the DVD/CD master option picked, so it gave me a *.cdr image file. I got the md5 hash of both the ORIGINAL iso file and the *.cdr made from the CD made from the original. Their hashes matched, therefore they were IDENTICAL. Here's the syntax for finding the md5 hash of any file in Mac OS (or Linux) through terminal:
Code:
openssl md5 [Drag file into terminal here to insert the path to that file, but don't forget the space between 'md5' and the path.]
Code:
hdiutil makehybrid -iso -joliet -o Master.iso Master.cdrDoes this mean Robbieduncan's method is bad? Of course not! His method is intended for building images from scratch (using source files and folders), not making images of existing CDs.
Note that dd adds extra zeros to the end of image files it makes of CDs. Most programs (including Disk Utility) do not add extra zeros. This will make the hash of a dd-made iso not match the hash of a Disk-Utility-made iso, even if you use the same physical CD to do both. I have tested this myself. It adds zeros to the file until the file size in bytes is a "nicer" looking number. Dd-made isos are still good.
And tgage, although dd can dump an audio CD to an image file, it is a mistake to name such a dump with the file extension "iso", even though nothing stops you from doing it. The act of naming a file with the extension "iso" is saying to every person who looks at that file that "this file is a CD image with an ISO 9660 compatible filesystem and is comprised of only one track." That's what people educated in this area expect when they see a file named with that file extension (not that you're not educated, because obviously you are). It's a naming convention standard, and it is the definition of an iso image file. The iso image standard only allows for one track. Audio CDs not only usually have more than one track, none of these tracks have a filesystem. Each track is raw digital audio data. An audio CD is pretty much a digital record, where the player just fires its laser at the disc, lets it spin, and the data coming out is directly interpreted as sound, without the need of a driver to understand a filesystem (as it would need if the audio data was instead a sound file in the ISO 9660 filesystem, or even the HFS+ for that matter), and it also does not need the ability to parse the file after finding the file with such a driver. There is still structure, but not as intense as say a thumb drive or regular CD/DVD.
So Calatis, it appears that you used an iso burning program to burn the dump you made of an audio CD to a physical CD. I imagine that you (no offense) misnamed the dump with the *.iso extension, then told an iso burning program to burn this non-iso to a CD. Iso burning programs are geared for burning isos, at least while they are burning one to a disc. There are two burning modes, TAO and DAO. They are Track at Once and Disc at Once. Disc at Once allows for more direct control of the hardware than Track at Once allows. Audio CDs have a very strange structure (no filesystem, multiple tracks, etc.) and therefore need the more direct hardware access offered by DAO to be burned (can't make this wierd structure with the limits of TAO). Actual isos (no offense, tgage
) can be burned with just the TAO method (because they are "normal," have a filesystem, have only one track, etc.). Therefore, it isn't unreasonable to suppose some iso burning programs only use TAO because that is all they need. When you forced an audio dump to be burned in TAO mode, it couldn't burn right because TAO can't burn some of the stuff in that dump (like song titles and all that stuff you said that went away). TAO also automatically inserted those 2-second gaps. Since it thought it was burning an iso (which only have one track), it is no wonder your audio CD came out to be one long track with 2-second pauses. Check this site out for more details. Also Calatis, note that Mac's iso mounter is not a true CD emulator. It does not actually emulate hardware at all. It is a pseudo-device. Pseudo-devices need a filesystem in the image file they are mounting to work. Pseudo-devices are the doing of the driver itself, and the whole system knows that the pseudo-device is not a real CD. It doesn't even try to make it look like hardware at all. A true CD emulator makes it impossible to know if the emulated CD reader is real or not. Because of the pseudo-device's need of a filesystem to mount an image file, and since the audio dump has no filesystem (made from disc with no filesystem), Mac could not mount the audio CD image. In contrast, Magic Disc, a true CD emulator for Windows, can mount audio disc images properly, and you can play the music right off the emulated drive as if it were a real audio CD.
Last edited:
SpawnHappyJake, order doesn't matter on those command line options.
Additionally, you can create the iso of a folder straight with hdiutil and skip the step of using Disk Utility first.
ex
This would make an ISO called image.iso on my Desktop, using the contents of the folder Desktop/someFolder to create the ISO.
Additionally, you can create the iso of a folder straight with hdiutil and skip the step of using Disk Utility first.
ex
Code:
hdiutil makehybrid ~/Desktop/someFolder -iso -joliet -o ~/Desktop/imageThis would make an ISO called image.iso on my Desktop, using the contents of the folder Desktop/someFolder to create the ISO.
That's Cool! ...but my hdiutuls is still backwards
Headrush69, that's pretty cool that you can make an iso right out of a folder with hdiutils - I didn't know that one! Saves time for sure.
I tried switching hdiutil makehybrid -iso -joliet -o [output] [input] to having [input] then [output]. It wants it as [output] then [input]. No biggy. Maybe your version doesn't care, or maybe we're using slightly different commands. I'm running Snow Leopard.
Just as a reminder to readers - there is imaging (dumping a disc), and there is image building (constructing an image from scratch that can then be burned to a disc). There are also images that aren't a raw dump, but they are out of context here. Headrush69 and I are talking about constructing an image from a folder here at this moment, rather than dumping a disc.
Headrush69, that's pretty cool that you can make an iso right out of a folder with hdiutils - I didn't know that one! Saves time for sure.
I tried switching hdiutil makehybrid -iso -joliet -o [output] [input] to having [input] then [output]. It wants it as [output] then [input]. No biggy. Maybe your version doesn't care, or maybe we're using slightly different commands. I'm running Snow Leopard.
Just as a reminder to readers - there is imaging (dumping a disc), and there is image building (constructing an image from scratch that can then be burned to a disc). There are also images that aren't a raw dump, but they are out of context here. Headrush69 and I are talking about constructing an image from a folder here at this moment, rather than dumping a disc.
You can make an ISO image from a folder using Disk Utility
You can make an ISO image from a folder using Disk Utility.
1. Put the files you want in the image into a folder.
2. Run Disk Utility in Utilities folder in Applications.
3. Don't click on the New Image icon - this doesn't work. Goto the menu and select:-
File-> New -> Disk Image From Folder...
4. Then select the folder from the File Open dialogue box that appears and click open.
5. In the Save As dialogue that appears change nothing apart from the "Image Format:" option. Select the bottom option that is "Hybrid Image (HFS+/ISO/UDF)"
6. Then press save. Disk Utility will produce a window with a progress bar. When complete the image will have been made.
7. The image will have a .dmg extension. Rename this to .iso. In the dialogue box that appears press the "Use .iso" button.
Don's use "CD/DVD Master". This produces a .cdr image that is not an ISO image.
Note these images open in VirtualBox as ISO images. The .cdr ones don't.
You can make an ISO image from a folder using Disk Utility.
1. Put the files you want in the image into a folder.
2. Run Disk Utility in Utilities folder in Applications.
3. Don't click on the New Image icon - this doesn't work. Goto the menu and select:-
File-> New -> Disk Image From Folder...
4. Then select the folder from the File Open dialogue box that appears and click open.
5. In the Save As dialogue that appears change nothing apart from the "Image Format:" option. Select the bottom option that is "Hybrid Image (HFS+/ISO/UDF)"
6. Then press save. Disk Utility will produce a window with a progress bar. When complete the image will have been made.
7. The image will have a .dmg extension. Rename this to .iso. In the dialogue box that appears press the "Use .iso" button.
Don's use "CD/DVD Master". This produces a .cdr image that is not an ISO image.
Note these images open in VirtualBox as ISO images. The .cdr ones don't.
cdr can equal iso
I have taken an iso, burned it to a disc, made an Apple *.cdr image of the physical disc, and taken both the md5 hash of the iso and the cdr. They matched. That means that the files are identical.
If Disk Utility shows the text "APPLE_ISO" as it is making it, I would bet it's an iso. That's what it showed when I made the above cdr.
That means that at least in that situation, a cdr image is an iso. There might be other cdr images that do not equal isos, but, dmoriarty, I would encourage you to double check. Rename the *.cdr file to *.iso, and see if VirtualBox takes it.
Cheers,
Jake
I have taken an iso, burned it to a disc, made an Apple *.cdr image of the physical disc, and taken both the md5 hash of the iso and the cdr. They matched. That means that the files are identical.
If Disk Utility shows the text "APPLE_ISO" as it is making it, I would bet it's an iso. That's what it showed when I made the above cdr.
That means that at least in that situation, a cdr image is an iso. There might be other cdr images that do not equal isos, but, dmoriarty, I would encourage you to double check. Rename the *.cdr file to *.iso, and see if VirtualBox takes it.
Cheers,
Jake
Last edited:
Correctional Ammendments
1.
The original question:
I responed to the "and have it compatible with Mac and Windows" part by saying:
I now want to ammend that.
I didn't have the knowledge I do now when I said that. An optical disc is bizarre. I shouldn't explain the whole scoop on them here, but to put it in a nutshell, there sure ain't any sectors on one. Optical sectors are made up. They are pieced together, calculated, and deduced by the optical drive's firmware. So the amount of processing of this madness that a certain imaging technique uses determines how "raw" the image is. No image is an exact representation of the data actually on the disc. ISOs are just the 2048-byte sectors in order that have been deduced from the disc, and that's what I meant by "raw" back then - as opposed to a "smart" image that is a list of observed properties and archived files that are used to reconstruct the disk when the image is applied (not a sector-based imaging approach). ISOs leave out subchannel info, which is not contained in sectors. RAW DAO 96 gets the 2328-byte sectors (which, in the case of most data discs, are boiled down to 2024-byte sectors - 304 of those bytes are error correction, point being RAW DAO 96 gets those 304 bytes) as well as all 96 bytes of subchannel info. But RAW DAO 96 is still a far cry from what's actually on the disc. Audio discs have 2328-byte-final-product sectors and don't have that third, last error correction (didn't mention the first two error corrections).
However, it still stands that an image that is "raw" in the sense that it is merely a string of sectors can't be incompatible. No processing has to be done. It doesn't have to be decompressed with a certain algorithm or parsed according to a syntax. If it did, you would need that syntax or algorithm to use the file. If you didn't have one of those, you wouldn't be able to use the "smart" image.
A string of sectors given the file extension "cdr" and a string of sectors given the file extension "iso" equally don't need to be processed, and are thus equally "immune" to incompatibilities, though a program may refuse to use one or the other on basis of file name, in which case a simple rename will fix that.
2.
I have since learned of a flaw in current kernel-level hardware emulation: floating branches. Emulated hardware from kernel-level emulation (at least the ones I've seen) look like "floating branches" in that they are not connected to the hardware tree. For example, Virtual CloneDrive's virtual optical drive is plugged into to Virtual CloneDrive's virtual SCSI controller. What is the virtual SCSI controller controller plugged into? Nothing. It's reported to be at a "virtual location". A real optical drive (or any kind of drive for that matter) would be plugged into a controller plugged into a PCI bus plugged into an ACPI plugged into the processor (more or less like that). The trunk of the hardware tree is the processor.
Keep it tecky
Jake
1.
The original question:
I responed to the "and have it compatible with Mac and Windows" part by saying:
I now want to ammend that.
I didn't have the knowledge I do now when I said that. An optical disc is bizarre. I shouldn't explain the whole scoop on them here, but to put it in a nutshell, there sure ain't any sectors on one. Optical sectors are made up. They are pieced together, calculated, and deduced by the optical drive's firmware. So the amount of processing of this madness that a certain imaging technique uses determines how "raw" the image is. No image is an exact representation of the data actually on the disc. ISOs are just the 2048-byte sectors in order that have been deduced from the disc, and that's what I meant by "raw" back then - as opposed to a "smart" image that is a list of observed properties and archived files that are used to reconstruct the disk when the image is applied (not a sector-based imaging approach). ISOs leave out subchannel info, which is not contained in sectors. RAW DAO 96 gets the 2328-byte sectors (which, in the case of most data discs, are boiled down to 2024-byte sectors - 304 of those bytes are error correction, point being RAW DAO 96 gets those 304 bytes) as well as all 96 bytes of subchannel info. But RAW DAO 96 is still a far cry from what's actually on the disc. Audio discs have 2328-byte-final-product sectors and don't have that third, last error correction (didn't mention the first two error corrections).
However, it still stands that an image that is "raw" in the sense that it is merely a string of sectors can't be incompatible. No processing has to be done. It doesn't have to be decompressed with a certain algorithm or parsed according to a syntax. If it did, you would need that syntax or algorithm to use the file. If you didn't have one of those, you wouldn't be able to use the "smart" image.
A string of sectors given the file extension "cdr" and a string of sectors given the file extension "iso" equally don't need to be processed, and are thus equally "immune" to incompatibilities, though a program may refuse to use one or the other on basis of file name, in which case a simple rename will fix that.
2.
I thought Calatis might have been trying to mount that image because I know that audio images can't be mounted with a pseudo-device since they have no filesystem. So I gave the obligitory note that simply mounting an iso doesn't equal optical drive emulation, and that the whole point of hardware emulation is to make illusionary hardware that is indistinguishable from real hardware.
I have since learned of a flaw in current kernel-level hardware emulation: floating branches. Emulated hardware from kernel-level emulation (at least the ones I've seen) look like "floating branches" in that they are not connected to the hardware tree. For example, Virtual CloneDrive's virtual optical drive is plugged into to Virtual CloneDrive's virtual SCSI controller. What is the virtual SCSI controller controller plugged into? Nothing. It's reported to be at a "virtual location". A real optical drive (or any kind of drive for that matter) would be plugged into a controller plugged into a PCI bus plugged into an ACPI plugged into the processor (more or less like that). The trunk of the hardware tree is the processor.
Keep it tecky
Jake
.toast images are exactly identical to .iso , Toast Titanium simply prefers to give images the .toast extension for commercial reasons.
I'm not sure if this is prefered way to resurrect this old thread, but I have used this thread as a reference and now I have a question.
Btw, seems to be, that even Apple's philosophy is, that user doesn't need to know what's really happening under the hood, it would be better, if there would be simplified explanations why things are what they are. Very good example is that people don't understand the difference between file formats and name extensions. Or that optical disks do have filesystems and there's more than one filesystem for them.
But here's the question: I recently wanted to rip Blade Runner's "Dangerous Days" documentary from dvd and I always rip to .iso, so it's easy to read with any operating system. This time I decided to make it two different ways. First was with Disk Utility to "DVD/CD master" and just changing the extension and the second method was with Aurora Blu-ray Copy to straight to .iso. Then I checked md5 hash and there was a difference.
Now I'd like to hear some educated guesses from "people in the know" which rip is "better". Anyone?
Btw, seems to be, that even Apple's philosophy is, that user doesn't need to know what's really happening under the hood, it would be better, if there would be simplified explanations why things are what they are. Very good example is that people don't understand the difference between file formats and name extensions. Or that optical disks do have filesystems and there's more than one filesystem for them.
But here's the question: I recently wanted to rip Blade Runner's "Dangerous Days" documentary from dvd and I always rip to .iso, so it's easy to read with any operating system. This time I decided to make it two different ways. First was with Disk Utility to "DVD/CD master" and just changing the extension and the second method was with Aurora Blu-ray Copy to straight to .iso. Then I checked md5 hash and there was a difference.
Now I'd like to hear some educated guesses from "people in the know" which rip is "better". Anyone?
Ok so i am trying to make one and it says no such directory created or found i entered the right command and everything any ideas??Thank you!
Thanks a lot, really helped!