Jump to content

Martin N

Members
  • Posts

    16
  • Joined

  • Last visited

Martin N's Achievements

ISF Newbie

ISF Newbie (1/5)

  1. 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!
  2. Thank you for the lightning-fast response! 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. 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...
  3. 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.
  4. 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!
  5. 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!
  6. 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).
  7. 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
  8. 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!
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. 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...
  14. 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) I 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
  15. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.