radorn Posted May 9, 2016 Posted May 9, 2016 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?
LIGHTNING UK! Posted May 10, 2016 Posted May 10, 2016 There's an old issue with the cd speeds (just the translation into '???x'). It was fixed at the time of the report, but that fix isn't present in any 'released' versions of the program. http://forum.imgburn.com/index.php?/topic/21692-2580-cd-burning-speed The value in the log comes from the drive itself. Different drives report different values. 176 is frequently used for 1x CD speed... but then so is 150. Google the 2 values (along with the term 'cd speed') and maybe you'll find the answer?!
radorn Posted May 11, 2016 Author Posted May 11, 2016 (edited) 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 KiB2352 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. Edited May 11, 2016 by radorn
LIGHTNING UK! Posted May 11, 2016 Posted May 11, 2016 I don't recall the value that was being used for the conversion to an 'x' rating in 2.5.8.0. My only hope is that the one it's using now works correctly! Specifically, the 'effective write speed' log entry takes the value from the drive. It queries it to find the current write speed and displays it 'as is' in the log. The value is in KB/s according to the MMC specs. I then do my best to guess at the 'x' speed it relates to... but I don't really know if it's using 1000 as a KB or 1024 as a KB. As I say, different drives do different things.
radorn Posted May 11, 2016 Author Posted May 11, 2016 (edited) 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?) I 16:39:25 Operation Started!I 16:39:25 Source File: U:\XXXXXXXX.isoI 16:39:25 Source File Sectors: 354.131 (MODE1/2048)I 16:39:25 Source File Size: 725.260.288 bytesI 16:39:25 Source File Volume Identifier: <XXXXXXXX>I 16:39:25 Source File Volume Set Identifier: <XXXXXXXX>I 16:39:25 Source File Application Identifier: CDIMAGE 2.47 (10/12/2000 TM)I 16:39:25 Source File File System(s): ISO9660 (Bootable); JolietI 16:39:25 Destination Device: [6:0:0] HL-DT-ST DVDRAM GH24NSD1 LE00 (O:) (SATA)I 16:39:25 Destination Media Type: CD-R (Disc ID: 97m17s06f, Moser Baer India)I 16:39:25 Destination Media Supported Write Speeds: 16x; 32x; 40x; 48xI 16:39:25 Destination Media Sectors: 359.847I 16:39:25 Write Mode: CDI 16:39:25 Write Type: SAOI 16:39:25 Write Speed: 1xI 16:39:25 Lock Volume: YesI 16:39:25 Test Mode: YesI 16:39:25 OPC: YesI 16:39:25 BURN-Proof: EnabledW 16:39:25 Write Speed Miscompare! - Wanted: 176 KB/s (1x), Got: 2.822 KB/s (16x)W 16:39:25 The drive only supports writing these discs at 16x; 32x; 40x; 48x. 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 I 16:44:48 Operation Successfully Completed! - Duration: 00:05:22I 16:44:48 Average Write Rate: 2.425 KiB/s (14.1x) - Maximum Write Rate: 2.451 KiB/s (14.2x) 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. Edited May 11, 2016 by radorn
LIGHTNING UK! Posted May 11, 2016 Posted May 11, 2016 The program uses the Mode 1 / 150KB/s speed for its CD speed calculations. For transfer rate 'x' values, the appropriate 1x speed is *calculated* rather than *picked* from a list - where the list would have to cover 2048, 2332, 2336, 2352 and 2448 sector sizes. Speed = KBs / (150 / (2048 / sectorsize)) So it's a calculation rather than 'switch / case' or 'if' statements. Right or wrong, that's just the way I've done it. I think it must be the '150' in the above calculation that is using a different constant/value in v2.5.8.0.
radorn Posted May 13, 2016 Author Posted May 13, 2016 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!
LIGHTNING UK! Posted May 13, 2016 Posted May 13, 2016 That's the formula as it currently stands in the unreleased version. I don't recall which figure / calculation was being used in 2.5.8.0
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now