CD speed gauge is puzzling me.

[radorn]

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!]

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]

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.

Edited May 11, 2016 by radorn

[LIGHTNING UK!]

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]

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.iso
I 16:39:25 Source File Sectors: 354.131 (MODE1/2048)
I 16:39:25 Source File Size: 725.260.288 bytes
I 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); Joliet
I 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; 48x
I 16:39:25 Destination Media Sectors: 359.847
I 16:39:25 Write Mode: CD
I 16:39:25 Write Type: SAO
I 16:39:25 Write Speed: 1x
I 16:39:25 Lock Volume: Yes
I 16:39:25 Test Mode: Yes
I 16:39:25 OPC: Yes
I 16:39:25 BURN-Proof: Enabled
W 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:22
I 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!]

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]

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!]

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