Jump to content

radorn

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by radorn

  1. Sorry, I didn't intend to annoy or critizise you, I was just trying to figure out what was happening. I presented what I found out while trying to come up with a process that would give the same results as I was getting. Didn't intend to impose my method or anything. I guess tend to sound rather imposing, so I apologize for that. Anyways: So, the formula is "KiB/s / (150 / (2048 / MODE#)) = #X"? Drom the previous quoted log for a MODE1/2048 operation, I'll take the reported "Maximum Write Rate: 2.451 KiB/s (14.2x)" and fill in the formula: 2451 / (150 / (2048 / 2048)) = 16.34 this would be the correct answer, but doesn't seem to match what the program spits out. but... 2451 / (150 / (2048 / 2352)) = 14,228027210884353741496598639456 does match indeed. Now, If that's what's happening indeed, then RAW mode burns should always show the correct info, but my previous MODE2/2352 @ 4x attempt that reported "691 KiB/s (3.5x)" reveals this: 691 / (150 / (2048 / 2352 )) = 4,01124716553287981859410430839 doesn't match at all while... 691 / (176 / (2048 / 2352 )) = 3,4186765615337043908472479901051 seems to match much better, but not quite. perhaps, it needs a little further tweak: 176400 B/s doesn't translate to 176KiB/s, but rather, 172,265625 KiB/s, let's try that: 691 / (172 / (2048 / 2352 )) = 3,4981806676158835627274165480146 ah yes, that's much better. So, it seems that, in the end, there is, indeed, some strange action here with mismatched sector sizes. Until it gets eventually fixed some day, at least now I know what's going on with them crazy speeds Anyway, thank you for taking your time and bearing with me. And for making ImgBurn, of course!
  2. Well, the log always seems to match data rate to Xs correctly when SETTING the speed for the operation; that is, taking into account that it's going to be mode2 speed, even when you are writing in mode1. (Could it be that ImgBurn converts MODE1 data to RAW for burning?) 2352 @16x = 2822400, so that's OK, even if it got me scratching my head xD But when it comes to MEASURING, things go strange. The real-time monitoring in the main window, and also the final report in the log seem to follow the formula I calculated before 1: multiply data rate by 1024 (because it's rounded up to KiB/s for display?) 2: divide by current sector size (2048 or 2352) 3: multiply by MODE1 sector size (2048) 4: divide by 1X RAW speed in bytes (176400) voilá! Whichever element is responsible for this (drive, software or whatever), is doing some strange stuff xD The last 3 steps could be replaced by a single step: division by 1x speed in B/s for current data mode.
  3. I couldn't find that through searches, but I made some calculations: First we have the canonical 1X speeds for mode1 and mode2/redbook 2048 x 75 = 153600 B -> 150 KiB 2352 x 75 = 176400 B -> 172,265625 KiB Then, if burning mode1 data, it seems that somehow the actual data rate is reflected correctly in the window, about 600 in this case, but the conversion is off, because, in this model, it would be divided by the mode2 rate: 600 x 1024 = 614400 -> 614400 / 176400 = 3,4829931972789115646258503401361 = ~3.5x Then, you'd expect mode2 to work right, but it seems like it doesn't, because it now should say 4 and still says 3.5: 691 x 1024 = 707584 -> 707584 / 176400 = 4,01124716553287981859410430839 =/= 3.5x One formula that seems to give the incorrect answer in both modes would be if the conversion to Xs is done looking at the number of sectors completed per second but then using the same mismatched conversion to bytes as before: 4x x 75sect = 300sect -> 300 x 2048 / 176400 = 3,4829931972789115646258503401361 Now it doesn't matter what the actual user data sector size is. could this be what's happening under the hood? Also, it seems that the log always gives data rates matched to mode2 sector size, whether you are burning mode1 or mode2.
  4. ImgBurn's log says: 21:34:53 Write Speed Successfully Set! - Effective: 706 KB/s (4x) But MODE1 single speed is 150 KB/s, therefore, for 4x : 2048 x 75 x 4 / 1024 = 600 KB/s Even in RAW/RedBook mode, 4x is not 706 KB/s but rather : 2352 x 75 x 4 / 1024 = 689,0625 KB/s If we take the proposed speed : 706 x 1024 / 4 = 180736 B/s -> 180736 / 75 = 2409,8133... bytes per sector? Even trying to calculate sector sizes for neighboring values of 705 and 707 KB/s (just to rule out rounding), I end up with possible sector sizes between 2406 and 2413, and I couldn't find any references for anything in that range. Anyway. When I burn at 4x, I get this: So, the data rates DO match 4x, but ImgBurn calls them 3.5x. Why is this and where does the "706 KB/s = 4x" figure come from?
  5. I'm starting to suspect newer versions of ImgBurn have problems with producing working gamecube burns, while it previously worked perfectly. Unfortunatelly I don't remember which version I used last time I had it work, but I know last time it was some earlier version (possibly something earlier than 2.5.0.0). I am now the owner of 4 Verbatim DVD+R coasters. The last one I tried, I ripped one of my WORKING burns and burned it again, and the new burn doesn't work. Here's the data of the "ORIGINAL" WORKING BURN Now the LOG of the process where I dump the working disc burn to an image and then burn it to a blank disc. And, finally, the data for the new NON-WORKING burn... ...which turns out to be IDENTICAL to the working copy. Any clues as to what's causing the production of coasters?
×
×
  • Create New...

Important Information

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