Martin N
-
Posts
16 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Martin N
-
-
Thank you for the lightning-fast response!
To be honest, I've never seen one where Formatted is different to Raw. Then again, my program always shows Raw where possible and falls back to Formatted when it's not available (as is the case with DVD/HD DVD/Blu-ray) - so I wouldn't have ever noticed it anyway.
Oh and yes, you'd expect Formatted to be an interpretation (slightly cleaner looking version) of Raw data but I guess that's not always the case!
Perhaps the 'Formatted' info uses something from the 'Track Information' to make up it's numbers... I really have no idea!
I looked at the different modes in CDTool and indeed the "formatted" and "raw" view in the mode entitled "full TOC info" returns the same information consistent with your "TOC info" (i.e. Track 8 start at 38:35:00 or sector 173475). The mode entitled "all complete sessions TOC info" (which I mistook for the formatted version of raw TOC data) is consistent with your "track info" (i.e. Track 8 start at 38:35:15 or sector 173490). I used CDTool to check subchannel Q data for sector 173475 and 173490, and the latter appears to be the correct start of Track 8, as the pre-track gap count-down is at 0, whereas for 173475 it is at 15.
The only people that could answer that question are the ones programming the firmware in the drive.I would have assumed all this stuff came directly from the drive so moving it between computers shouldn't have made any difference. It's very weird if you're saying it did - perhaps some filter driver is messing things up?
Unfortunately, I think the firmware is off the hook for now, considering the differences in behaviour of the drive in two different systems. I kind of feared this would happen, as things just got a bit more complicated. I will post any new developments...
-
I query the Raw TOC, CDTool queries the Formatted TOC (by default anyway - change 'Read TOC format' to 'All TOC info' to make it read Raw TOC). I expect that's where the difference is coming from.
You were correct, LUK! In the raw mode, CDTool and ImgBurn reported the same thing on ND-3540A. Why would formatted and raw mode reading of TOC differ? Is the formatted form not just an interpretation of the raw data? I apologize if my ignorance is showing
On another note, I removed GDR-H30N, which behaves "correctly" on machine A (i.e. raw and formatted TOC info is the same), and tried it in machine B, which is normally equipped with ND-3540A. To my surprise, GDR-H30N started to behave "incorrectly" (i.e. raw and formatted info is NOT the same). Knowing the nuts and bolts of disc drive reading/writing, can you suggest which aspect of the hardware/operating system could be responsible for the difference?
Thanks again for continuing this discussion with me - I am a bit unsettled by this apparent dependence of disc drive performance on the host computer system.
-
Yes, when ripping from an image. As it is now, ImgBurn reads a disc with the offset determined by the drive make and model. It then generates the disc image, which carries the same read offset. Then, if I want to make an accurate track from the image, I have to set EAC to the same read offset as the image. Considering that several different drives may be used to create images, this may be problem. What I am suggesting is that all CD-AD images be normalized (by padding with "silence" as per EAC method) to read offset of zero. Then all tracks from any image (independent of the source drive) could be accurately ripped with EAC set to the same read offset, i.e. zero.
Thanks!
-
EAC has been doing what it does for years, ImgBurn is no where near as mature/accurate for audio stuff.
The 'GCR-8523B' is just useless - period.
It's unlikely you'd notice 15/75th's of a second difference (of what's probably just 'silence') so just use whatever you're comfortable with.
Hi LUK!
I understand that pre-track gap may be subject to some variability, as it is being detected from sub-channel Q-data. However, I thought that the start time/sector of a track should be taken from the TOC in the lead-in area, which is fixed. Even GCR-8523B gets it right... I looked at the disc in ND-3540A using CDTool, and the TOC entry for Track 8 conforms to EAC (starting LBA 173490) not ImgBurn (starting LBA 173475), although ImgBurn track information indicates LBA 173490.
Thanks!
-
Well, if you really care about the quality of the songs, there's no alternative than to use EAC to rip your songs and use either EAC or Burrrn to burn your songs with proper offset correction.
Imgburn is not a replacement to EAC, and I don't think it intends to be.
I am not as much interested in burning the images back onto a physical medium, as I am in getting reasonable electronic backups of the originals. EAC is great for extracting audio data but it does not do images of combination discs, i.e. discs with audio and data sessions included. I like the way ImgBurn keeps the original binary (BIN), CD-TEXT (CDT), and TOC/pre-track gap (CUE) information separately. I have compared many of my Audio CD images created by ImgBurn to EAC output, and I have yet to find an error (per AccurateRip and CRC32) - most of my CDs are in a good condition. I accept the lack of C2 error detection as a shortcoming of ImgBurn, and understand if it is not a high priority in its development.
What I suggested above involves a simple shift in the BIN sequence (and padding with zeroes the gap at the start or the end) to compensate for the read offset, so that it more accurately represents the original (and obviates the need to memorize the read offset for each image).
-
Hello;
I would be very grateful for any suggestions that would help me to explain, and eliminate, the following discrepancies in CUE information regarding the pre-track gap preceding Track 8.
During some experimenting I converted the same Audio CD into image files using Exact Audio Copy (EAC) and ImgBurn with four different disc drives: GCR-8523B (CD-ROM), GDR-H30N (DVD-ROM), GDR-8162B (DVD-ROM), and ND-3540A (DVD-RW). As can be seen below, CUE information generated by EAC is the same for all four drives (in terms of the duration of Track 7 and 8).
However, ImgBurn detected the pre-track gap differently in two of the drives: Whereas GCR-8523B and GDR-H30N values were identical (within a frame) to EAC, GDR-8162B and ND-3540A detected pre-track gap that starts sooner by 15 frames, therefore correspondingly shortening Track 7 and extending Track 8.
I am not sure if this is relevant, but GCR-8523B and GDR-H30N are on one computer, and GDR-8162B and ND-3540A on another, but both machines run the same operating system and the same version of ImgBurn and EAC.
Thanks!
GCR-8523B
ImgBurn CUE
...
TRACK 07 AUDIO
INDEX 01 34:28:15
TRACK 08 AUDIO
INDEX 01 38:33:15
EAC CUE
...
TRACK 07 AUDIO
TITLE "Track07"
PERFORMER "Unknown Artist"
INDEX 01 34:28:15
TRACK 08 AUDIO
TITLE "Track08"
PERFORMER "Unknown Artist"
INDEX 01 38:33:15
GDR-H30N
ImgBurn CUE
...
TRACK 07 AUDIO
INDEX 01 34:28:15
TRACK 08 AUDIO
INDEX 00 38:31:69
INDEX 01 38:33:15
EAC CUE
...
TRACK 07 AUDIO
TITLE "Track07"
PERFORMER "Unknown Artist"
INDEX 01 34:28:15
TRACK 08 AUDIO
TITLE "Track08"
PERFORMER "Unknown Artist"
INDEX 00 38:31:70
INDEX 01 38:33:15
GDR-8162B
ImgBurn CUE
...
TRACK 07 AUDIO
INDEX 01 34:28:15
TRACK 08 AUDIO
INDEX 00 38:31:54
INDEX 01 38:33:00
EAC CUE
...
TRACK 07 AUDIO
TITLE "Track07"
PERFORMER "Unknown Artist"
INDEX 01 34:28:15
TRACK 08 AUDIO
TITLE "Track08"
PERFORMER "Unknown Artist"
INDEX 00 38:31:70
INDEX 01 38:33:15
ND-3540A
ImgBurn CUE
...
TRACK 07 AUDIO
INDEX 01 34:28:15
TRACK 08 AUDIO
INDEX 00 38:31:54
INDEX 01 38:33:00
EAC CUE
...
TRACK 07 AUDIO
TITLE "Track07"
PERFORMER "Unknown Artist"
INDEX 01 34:28:15
TRACK 08 AUDIO
TITLE "Track08"
PERFORMER "Unknown Artist"
INDEX 00 38:31:70
INDEX 01 38:33:15
-
Why are you reripping the disc if you already have the files ("images of Audio CDs mounted with DAEMON Tools")?
Mainly to confirm that ImgBurn has created a good image (AccurateRip), considering that it does not use C2 error detection. Also, I want to be able to rip tracks accurately from the image, should the need arise.
Thanks for the response!
-
Hello;
I used Exact Audio Copy (EAC) to extract tracks from ImgBurn BIN/CUE images of Audio CDs mounted with DAEMON Tools. If I set the read offset in EAC to the value used on the source disc drive (i.e. drive used to create the image), the resulting tracks have the same CRC32 as those extracted directly from the disc, and verified by AccurateRip. The problem is that one needs to remember on which drive the BIN/CUE image was created. It would be nice to have an option to input the read offset into ImgBurn, which would produce BIN/CUE images padded with zeroes (at the start or at the end, depending on the direction of the read offset) to a standard zero read offset. The is the way EAC does it for drives unable to read into lead-in and lead-out segments anyway!
BTW, the last track extracted using EAC from an Audio CD disc with four disc drives (read offset: -24, +6, +48, +102) resulted in files with different CRC32 (due to different amount of padding required) but still produced the same AccurateRip checksum. The algorithm must somehow ignore the padded portion of the file...
Thanks!
Martin
-
If we've already dealt with this, why post it as a new thread and not just add to your previous one?
There's nothing I can do for the drive that errors out reading sector 0, that's its problem.
The other issue (with the INDEX) has already been fixed ready for the next release.
I have considered tagging it onto the end of the previous thread but it seemed to me that this is a different issue (even though it is associated with the same Audio disc).
The drive (that failed in this case) performs just fine with other "regular" Audio discs. I thought you might be interested because it appears to me that the failure occurs because of the unusual INDEX entry. Therefore, if this drive does it, others might have a similar problem. Also, ImgBurn did not abort the read - It had to be performed manually.
Finally, it is good to hear that something useful came out of our previous conversation.
-
Hi LUK!
This post is for your information - I don't know if this is a bug as such... I posted a while ago about difficulties with an Audio CD, which turns out to have an illegal value in the CUE file:
CATALOG 0075590010326
FILE "Eagles - Hotel California.bin" BINARY
TRACK 01 AUDIO
INDEX 00 00:00:00
INDEX 01 954437:09:46
TRACK 02 AUDIO
INDEX 00 06:28:41
INDEX 01 06:30:47
TRACK 03 AUDIO
INDEX 01 11:35:15
TRACK 04 AUDIO
INDEX 00 16:19:57
INDEX 01 16:21:57
TRACK 05 AUDIO
INDEX 00 21:15:17
INDEX 01 21:17:17
TRACK 06 AUDIO
INDEX 00 22:38:72
INDEX 01 22:40:72
TRACK 07 AUDIO
INDEX 01 26:50:45
TRACK 08 AUDIO
INDEX 00 30:49:09
INDEX 01 30:50:02
TRACK 09 AUDIO
INDEX 00 35:59:40
INDEX 01 36:01:40
I tested this CD on two different drives and I got two different behaviours by ImgBurn, while trying to create an image. Whereas GCR-8523B successfully performed the copy:
L-DT-ST CD-ROM GCR-8523B 1.01 (ATA)
Current Profile: CD-ROM
Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 195,677
Size: 400,746,496 bytes
Time: 43:31:02 (MM:SS:FF)
TOC Information:
Session 1...
-> PreGap (Audio, 954437:09:46, LBA: 0 - 4294967220)
-> Track 01 (Audio, 06:31:47, LBA: 4294967221 - 29296)
-> Track 02 (Audio, 05:04:43, LBA: 29297 - 52139)
-> Track 03 (Audio, 04:46:42, LBA: 52140 - 73631)
-> Track 04 (Audio, 04:55:35, LBA: 73632 - 95791)
-> Track 05 (Audio, 01:23:55, LBA: 95792 - 102071)
-> Track 06 (Audio, 04:09:48, LBA: 102072 - 120794)
-> Track 07 (Audio, 03:59:32, LBA: 120795 - 138751)
-> Track 08 (Audio, 05:11:38, LBA: 138752 - 162114)
-> Track 09 (Audio, 07:27:37, LBA: 162115 - 195676)
-> LeadOut (LBA: 195677)
ATIP Information:
Start Time of LeadIn (MID): 00m00s01f
Last Possible Start Time of LeadOut: 00m16s02f
I 15:20:19 Operation Started!
I 15:20:19 Source Device: [1:1:0] HL-DT-ST CD-ROM GCR-8523B 1.01 (F:) (ATA)
I 15:20:19 Source Media Type: CD-ROM
I 15:20:19 Source Media Sectors: 195,677
I 15:20:19 Source Media Size: 460,232,304 bytes
I 15:20:19 Source Media File System(s): None
I 15:20:19 Read Speed (Data/Audio): 8x / 8x
I 15:20:19 Destination File: C:\data\imgburn\Eagles - Hotel California.bin
I 15:20:19 Destination Free Space: 28,761,128,960 bytes (28,087,040 KB) (27,428 MB) (26 GB)
I 15:20:19 Destination File System: NTFS
I 15:20:19 File Splitting: Auto
I 15:20:26 Reading Session 1 of 1... (9 Tracks, LBA: 0 - 195676, MCN: 0009020236000)
I 15:20:26 Reading Track 1 of 9... (AUDIO/2352, LBA: 0 - 29296)
I 15:21:06 Reading Track 2 of 9... (AUDIO/2352, LBA: 29297 - 52139)
I 15:21:31 Reading Track 3 of 9... (AUDIO/2352, LBA: 52140 - 73631)
I 15:21:53 Reading Track 4 of 9... (AUDIO/2352, LBA: 73632 - 95791)
I 15:22:13 Reading Track 5 of 9... (AUDIO/2352, LBA: 95792 - 102071)
I 15:22:18 Reading Track 6 of 9... (AUDIO/2352, LBA: 102072 - 120794)
I 15:22:37 Reading Track 7 of 9... (AUDIO/2352, LBA: 120795 - 138751)
I 15:23:07 Reading Track 8 of 9... (AUDIO/2352, LBA: 138752 - 162114)
I 15:23:52 Reading Track 9 of 9... (AUDIO/2352, LBA: 162115 - 195676)
I 15:24:52 Exporting Graph Data...
I 15:24:52 Graph Data File: C:\Documents and Settings\XXXXXX\Application Data\ImgBurn\Graph Data Files\HL-DT-ST_CD-ROM_GCR-8523B_1.01_2009-09-15_3-20_PM_N-A.ibg
I 15:24:52 Export Successfully Completed!
I 15:24:52 Operation Successfully Completed! - Duration: 00:04:32
I 15:24:52 Average Read Rate: 1,652 KB/s (9.6x) - Maximum Read Rate: 2,793 KB/s (16.2x)
GDR-H30N just stalled after the error shown in red appeared, and the read had to be stopped using the Cancel button.
HL-DT-ST DVD-ROM GDR-H30N 1.00 (ATA)
Current Profile: CD-ROM
Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 195,677
Size: 400,746,496 bytes
Time: 43:31:02 (MM:SS:FF)
TOC Information:
Session 1...
-> PreGap (Audio, 954437:09:46, LBA: 0 - 4294967220)
-> Track 01 (Audio, 06:31:47, LBA: 4294967221 - 29296)
-> Track 02 (Audio, 05:04:43, LBA: 29297 - 52139)
-> Track 03 (Audio, 04:46:42, LBA: 52140 - 73631)
-> Track 04 (Audio, 04:55:35, LBA: 73632 - 95791)
-> Track 05 (Audio, 01:23:55, LBA: 95792 - 102071)
-> Track 06 (Audio, 04:09:48, LBA: 102072 - 120794)
-> Track 07 (Audio, 03:59:32, LBA: 120795 - 138751)
-> Track 08 (Audio, 05:11:38, LBA: 138752 - 162114)
-> Track 09 (Audio, 07:27:37, LBA: 162115 - 195676)
-> LeadOut (LBA: 195677)
Track Information:
Session 1...
-> Track 01 (LTSA: 4294967221, TS: 29370, LRA: 0)
-> Track 03 (LTSA: 52140, TS: 21490, LRA: 0)
-> Track 04 (LTSA: 73632, TS: 22158, LRA: 0)
-> Track 05 (LTSA: 95792, TS: 6278, LRA: 0)
-> Track 06 (LTSA: 102072, TS: 18721, LRA: 0)
-> Track 07 (LTSA: 120795, TS: 17955, LRA: 0)
-> Track 08 (LTSA: 138752, TS: 23361, LRA: 0)
I 15:18:55 Operation Started!
I 15:18:55 Source Device: [1:0:0] HL-DT-ST DVD-ROM GDR-H30N 1.00 (E:) (ATA)
I 15:18:55 Source Media Type: CD-ROM
I 15:18:55 Source Media Sectors: 195,677
I 15:18:55 Source Media Size: 460,232,304 bytes
I 15:18:55 Source Media File System(s): None
I 15:18:55 Read Speed (Data/Audio): 8x / 8x
I 15:18:55 Destination File: C:\data\imgburn\Eagles - Hotel California.bin
I 15:18:55 Destination Free Space: 28,761,137,152 bytes (28,087,048 KB) (27,428 MB) (26 GB)
I 15:18:55 Destination File System: NTFS
I 15:18:55 File Splitting: Auto
I 15:19:07 Reading Session 1 of 1... (9 Tracks, LBA: 0 - 195676, MCN: 0075590010326)
I 15:19:07 Reading Track 1 of 9... (AUDIO/2352, LBA: 0 - 29294)
W 15:19:07 Found end of Disc! - Sector: 0
I 15:19:35 Abort Request Acknowledged
E 15:19:35 Failed to Read Sectors!
I 15:19:35 Exporting Graph Data...
I 15:19:35 Graph Data File: C:\Documents and Settings\XXXXXX\Application Data\ImgBurn\Graph Data Files\HL-DT-ST_DVD-ROM_GDR-H30N_1.00_2009-09-15_3-18_PM_N-A.ibg
I 15:19:35 Export Successfully Completed!
E 15:19:35 Operation Aborted! - Duration: 00:00:40
E 15:19:35 Average Read Rate: N/A - Maximum Read Rate: N/A
EAC was also successful only with one but not the other drive. BTW, CUE file created by EAC during the successful read sets the strange INDEX value to 00:00:00.
Take care!
Martin
-
Hi LUK!
Thank you for all your time! I'll try to make a "legal" copy of the disc as you suggested. For the sake of completeness, I got the same info for the disc from a different drive (as expected, I suppose).
Take care and thanks for a great program!
Martin
P.S. I did a quick search for any information regarding this issue and came across a list of other CD oddities, maybe this is one of them...
http://desolationvalley.com/wj/oddcd/index.shtml.
Yeah, I made one up with a similar TOC and no program I've tried it in so far will play ball properly.You just don't ever get discs where the first track starts any time before 00:02:00 (MM:SS:FF), and on that disc it's at 00:01:00.
One thing's for sure, you will not be able to burn an exact copy from a BIN/CUE as the format doesn't allow for writing to the area you need to write to.
Your best bet would be to rip the tracks to individual wavs in EAC or something and then burn a new disc (with track 1 starting at 00:02:00 like it's supposed to).
-
Hi LUK!
I appreciate your interest and time. I am at work now and the disc is, of course, at home. However, previously I did try the whole procedure here at work (i.e. on another drive) with the same end result (i.e. being unable to mount it with DAEMON). Unfortunately, I don't have any documentation for this so I cannot provide you with the physical comparison of the disc info. I will do so once I get home, where I do have access to another DVD drive. It is starting to look like there is something funky with the disc...
Do you have access to any other drives?The TOC info for Track 1 is odd... very odd! (Look at the LBA value!)
Put the disc in any other drive you can find and see if the disc info text is the same as what you posted there.
-
Hi LUK!
Yes indeed, when I saw the number, I realized that it is likely the cause... I am attaching the requested screen shot and the readout from the text box.
BTW, as per DAEMON tech support advice I mounted the BIN file (rather than CUE), which was successful but the image was not readable by Win. The same situation when I mount BIN of a "good" BIN/CUE pair. It seems that DAEMON does not look for a corresponding CUE file when BIN is mounted... Either way, the evidence points to a malformed CUE file.
-------------------------------------------------------------
_NEC DVD_RW ND-3540A 1.04 (ATA)
Current Profile: CD-ROM
Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 195,677
Size: 400,746,496 bytes
Time: 43:31:02 (MM:SS:FF)
TOC Information:
Session 1... (LBA: 0 - 195676)
-> PreGap (Audio, 954437:09:46, LBA: 0 - 4294967220)
-> Track 01 (Audio, 06:31:47, LBA: 4294967221 - 29296)
-> Track 02 (Audio, 05:04:43, LBA: 29297 - 52139)
-> Track 03 (Audio, 04:46:42, LBA: 52140 - 73631)
-> Track 04 (Audio, 04:55:35, LBA: 73632 - 95791)
-> Track 05 (Audio, 01:23:55, LBA: 95792 - 102071)
-> Track 06 (Audio, 04:09:48, LBA: 102072 - 120794)
-> Track 07 (Audio, 03:59:32, LBA: 120795 - 138751)
-> Track 08 (Audio, 05:11:38, LBA: 138752 - 162114)
-> Track 09 (Audio, 07:27:37, LBA: 162115 - 195676)
-> LeadOut (LBA: 195677)
Track Information:
Session 1...
-> Track 01 (LTSA: 4294967221, TS: 29372, LRA: 0)
-> Track 02 (LTSA: 29297, TS: 22843, LRA: 0)
-> Track 03 (LTSA: 52140, TS: 21492, LRA: 0)
-> Track 04 (LTSA: 73632, TS: 22160, LRA: 0)
-> Track 05 (LTSA: 95792, TS: 6280, LRA: 0)
-> Track 06 (LTSA: 102072, TS: 18723, LRA: 0)
-> Track 07 (LTSA: 120795, TS: 17957, LRA: 0)
-> Track 08 (LTSA: 138752, TS: 23363, LRA: 0)
-> Track 09 (LTSA: 162115, TS: 33562, LRA: 0)
It's pretty obvious why it won't mount that.INDEX 01 954437:09:46I bet ImgBurn can't burn it either.
Please put the disc back in the drive and start ImgBurn as if you were about to read it to a new image.
Then click the 'disc information' button that's in the Source box.
Can you get me a screenshot of it?
Also, copy + paste the disc information text back on the right side of the main screen (where it says 'Current Profile' etc).
Thanks
-
Please post the contents of the CUE file (open it with Notepad).
Thank you for the quick reply! Following is the CUE file:
CATALOG 0075590010326
FILE "Eagles - Hotel California.bin" BINARY
TRACK 01 AUDIO
INDEX 00 00:00:00
INDEX 01 954437:09:46
TRACK 02 AUDIO
INDEX 00 06:28:41
INDEX 01 06:30:47
TRACK 03 AUDIO
INDEX 01 11:35:15
TRACK 04 AUDIO
INDEX 00 16:19:57
INDEX 01 16:21:57
TRACK 05 AUDIO
INDEX 00 21:15:17
INDEX 01 21:17:17
TRACK 06 AUDIO
INDEX 00 22:38:72
INDEX 01 22:40:72
TRACK 07 AUDIO
INDEX 01 26:50:45
TRACK 08 AUDIO
INDEX 00 30:49:09
INDEX 01 30:50:02
TRACK 09 AUDIO
INDEX 00 35:59:40
INDEX 01 36:01:40
-
Hello;
I have been using the combo of ImgBurn and DAEMON Tools to create and mount numerous CD and DVD images without any issues. Recently, I successfully (no error messages) created using ImgBurn v2.5.0.0 a BIN/CUE image of Eagles' Hotel California CD. However, when I try to mount it with DAEMON Tools Light v4.30.4.0027 I get an error box "Unable to mount image. Syntax error." (note there is no error number).
I don't know enough about CD structure or image formats to determine if there is something "funny" about the CD that causes ImgBurn to produce a faulty image, or something in DAEMON that prevents it from opening a properly formed image. I am in touch also with DAEMON technical support, but thought that ImgBurn experts might be able/interested to look into this strange problem. I have not found any similar issues while looking through the ImgBurn forum.
I am willing to supply the image file or any other diagnostic information you might require.
Thanks for your time!
Pad BIN/CUE images of Audio CDs to standardize to zero read offset
in ImgBurn Suggestions
Posted
I have no problem to merge this thread with another relevant topic (even if it appears to be dead
). BTW, if padding BIN files is not very likely to happen, would it at least be possible to generate CUE files containing the model/type of the source CD/DVD drive? The offset for the respective BIN should be then easy to determine if needed...
Thanks!