DT fails to mount .cue (but mounts .bin)

[slaegr]

G'day,

First of all, I just want to say I think DT (and similar tools) are great -- I use it mostly to allow my kids to play games on their computers, mounting images from the network. It means they don't need to fiddle around inserting & taking out disks -- not that their computers have working CD drives anyway.

What I wanted to notify you about was a disk I recently bought where DT is having trouble mounting the .cue file, but the .bin file mounts fine if done by itself. (The program was "Storybook Weaver Deluxe", if that is relevant.)

I usually make images using IsoBuster, extracting the raw data into a .bin file -- it also creates a .cue file next to it.

Now, my understanding is that the .bin file contains a 1:1 copy of everything on the disk, and is therefore all I need.

I'm not sure the purpose of the .cue file in this instance, apart from being a human-readable contents??? (of what is on the disk anyway).

Everything appears to work fine if I just get rid of the .cue file, but my problem is that the the filetypes in the Mount option of DT only list the .cue file type, but not .bin. (This makes it harder for my kids to select the file.)

Note that other disks work fine with (or without) the .cue file. The .cue file for Storybook Weaver also looks fine compared to other .cue files.

I know that I can just change the file extension, e.g. to .iso, and it then comes up in the file list, plus works fine when loaded.

I'm not really keen on doing that though, because (to my understanding), technically the .iso file should only contain the ISO file system data (2048 bytes per sector), whereas the file I have (.bin) actually contains the raw 2352 bytes.

Changing the name to .iso, whilst it works, would be technically the incorrect file type.

I was wondering if I am doing everything right, or is there another extension, which is recognised by DT, which is correct for a 1:1 image in the .bin format?

Otherwise, DT potentially has the following minor bugs:

- In some cases it does not load a .cue file correctly (even when the associated .bin file is correct). Note -- no obvious problems with the .cue file.

- Should the list of valid file types include .bin files (as well as, or instead of .cue files) -- in fact is the .cue file used at all, other than as a pointer to the .bin?

(i.e. what happens if the .cue file conflicts with the raw data on the disk)

Thanks in advance,

- Sly

[Copytrooper]

Just use a software creating correct cue images.
Daemon Tools does not contain any "bugs" you mentioned. Correct cue-sheets are mounted correctly. The cue-sheet is required TOC file, thus Daemon Tools mounts bin images with corresponding cue-sheet only, this is moreover the actually image file format cue+bin.
Btw just post the cue-sheet, then we'll see the problem ... what error do you get anyway?

[Mystique]

Plz tell me the name of the *bin and *cue and open the *cue with a texteditor and poost everthing in it here too.

[slaegr]

Thanks for the help so far.

First of all:

The cue-sheet is required TOC file, thus Daemon Tools mounts bin images with corresponding cue-sheet only

I don't see this happening -- if I delete the cue sheet, the bin file loads fine by itself (it even loads fine if you rename it to .iso or similar).

Besides, if the bin file contains a 1:1 copy of the data on the disk, and the cue file is autogenerated, then how can it have any information not already present?

I understand the situation where you have an audio disk where the raw data is only the music, and the cue file contains the jacket information (artist, album, song names) -- but for data disks it wouldn't seem relevant.

Anyway, I bought two disks for my kids recently, and ripped images files using IsoBuster for both of them to get them on the network.

The cue file that does not work is:

FILE "Storybook Weaver.bin" BINARY

REM ORIGINAL MEDIA-TYPE: CD

  REM SESSION 01        ; Not supported by other applications (*)
    TRACK 01 MODE2/2352
      INDEX 01 00:00:00
      REM MSF: 00:00:00 = LBA: 0

REM (*) SESSION directives are unfortunately not properly supported
REM     'out there'.  IsoBuster however supports them !

If I try to load the above cue file with DT, then the resulting virtual drive doesn't work; the cue file is listed in DT, but when accessing the drive Windows gives a "Not formatted" error.

Loading the bin file directly (or deleting the cue file, and loading the bin file, or renaming the bin file to iso and then loading) works fine -- software can be installed, etc.

The other software I bought at the same time was "Carmen Sandiego.cue", and works fine (when loading the cue file). Doing a diff (actually fc) on the two files gives:

C:\Temp>fc "Carmen Sandiego.cue" "Storybook Weaver.cue"
Comparing files Carmen Sandiego.cue and STORYBOOK WEAVER.CUE
***** Carmen Sandiego.cue
FILE "Carmen Sandiego.bin" BINARY

***** STORYBOOK WEAVER.CUE
FILE "Storybook Weaver.bin" BINARY

*****

***** Carmen Sandiego.cue
  REM SESSION 01        ; Not supported by other applications (*)
    TRACK 01 MODE1/2352
      INDEX 01 00:00:00
***** STORYBOOK WEAVER.CUE
  REM SESSION 01        ; Not supported by other applications (*)
    TRACK 01 MODE2/2352
      INDEX 01 00:00:00
*****

Apart from the name, the other difference appears to be the track format. Checking a spec for the cue file format (http://digitalx.org/cuesheetsyntax.php), the MODE2/2352 for Storybook Weaver is valid.

Could, for some reason, DT support MODE2 directly (loading the bin), but not when loading from a cue?

[Underheaven]

...

When you mount the .BIN, can you view in IsoBuster or Nero if DAEMON Tools thinks the image is mode1 or mode2?

[Jito463]

Have you tried simply changing it to MODE1 and trying again?

[Underheaven]

...

Have you tried simply changing it to MODE1 and trying again?

I think he already has a workaround but it looks like a bug if DAEMON Tools won't correctly mount the image via CUE file. That or ISObuster screwed something up in the BIN or CUE somewhere.

[slaegr]

When you mount the .BIN, can you view in IsoBuster or Nero if DAEMON Tools thinks the image is mode1 or mode2?

Okay -- more info:

When I mount the .bin, and then check the virtual drive in IsoBuster, it comes up as Mode 1.

Checking the original disk, it comes up in IsoBuster as format "Audio".

I don't think its weird copy protection, as you don't need the disk after install (but maybe it still checks for a legit disk during install?)

So, it seems that IsoBuster might be screwing up the .cue file, maybe (I still don't know enought to tell).

Anyway, I would still be interested in my second suggestion -- that is, having DT Mount show .bin files automatically; that is, have .bin files in the list of file types in the filter of Mount (Load).

Currently, to see the .bin file, I need to change the file filter to All (*.*) first, which is annoying.

As DT is mounting the disk, not playing it, then it only needs the image anyway; the meta-data about the playlist (if audio CD) is no use to it. (Anymore than to a normal CD drive) -- it just plays whats actually on the disk (not whats on the CD jacket cover).

So, should I move this to the feature request thread?

It shouldn't be too hard to add a file load filter for *.bin files (seeing as they are supported by DT, after all).

[Copytrooper]

bin won't be added to the filer, 'cause the format is cue/bin. The fact that the bin actually mounts is due to the fact that it is handled as iso then only, moreover this works only if the image contains one track only, thus the TOC file, i.e. the cue-sheet is required for this image file format.
If you want to avoid changing the filter to all *.*, either rename the .bin to .iso, or use a better imaging software. cue/bin is not able to handle modern protections anyway.