Transfer graphs and times

[KCK]

I'd like to present a simple formula for deducing transfer times from transfer rate graphs, such as those produced by Nero CD Speed; see the first three pictures in CDFreaks' review of Plextor Premium:

http://www.cdfreaks.com/article/112/4

A transfer rate graph plots the transfer speed V(s) (in units of 1x) as a function of the current position s (in units of 1 min = 60*75 sectors). The main idea is to approximate V(s) by a simple affine function of the form r*s + V_0, where the slope r >= 0 and the initial speed V_0 > 0 are chosen so that the graphs of the two functions are "close" (more on this later).

In our simplified model, s(t) is the position at time t elapsed since the start of the test; t is measured in "wall-clock" minutes. Since the derivative s'(t) of s(t) should satisfy s'(t) = V(s(t)), our approximation yields the simpler linear differential equation

s'(t) = r * s(t) + V_0 for t >= 0, with s(0) = 0.

Hence by standard arguments,

s(t) = V_0 * exp(r*t) * Int_0^t exp(-r*x) dx,

where exp(.) denotes exponentiation and Int_0^t stands for the integral over the interval [0,t]. Two cases arise.

For CLV (constant linear velocity), r = 0 and

s(t) = V_0 * t,

whereas for CAV (constant angular velocity), r > 0 and

s(t) = V_0 * [exp(r*t) - 1] / r.

Let T denote the total transfer time (in min). Then T = s(T)/V_0 for CLV, whereas for CAV (ln is the natural logarithm)

T = ln[ r * s(T) / V_0 + 1 ] / r.

In the typical case, we may choose the slope

r = (V_T - V_0) / s(T),

where V_T and V_0 approximate V(s(T)) and V(0); then

T = s(T) * ln(V_T / V_0) / (V_T - V_0).

For the three CDFreaks' pictures, choosing (V_0,V_T,s(T)) as (22,50,74), (23,50,72), (23,52,72) yields the times 2:10, 2:04, 2:01, whereas the actual times are 2:04, 2:01, 1:58 respectively. The agreement is quite suprising, in view of our simplifications.

In another example, suppose 10-24X CAV means the transfer speed starts at 10x and grows linearly to reach 24x at position M. Then for r = 14/M,

T = (M/14) * ln(1.4 * s(T) / M + 1),

so that, knowing T and s(T), we may estimate M.

Our model may be extended. For instance, for P-CAV, suppose V(s) grows from V_0 to V_T on [0,s_A] and equals V_T on [s_A,s(T)], where s_A is the switch position. Then

T = s_A * ln(V_T / V_0) / (V_T - V_0) + [s(T) - s_A] / V_T.

I'd like to ask able users (cfitz, dodecahedron, Inertia, MediumRare ...) to check my calculations, or to provide pointers if all this is well known!

[dodecahedron]

nice.
but my first comment (haven't read thoroughly yet) is that CAV is not truely CAV.
in the CDSpeed pics it's clearly seen that the RPM isn't really constant, it slightly decreases over time. and the speed v(s) isn't a linear function of s (as it should be for a "true" CAV), but slighly concave (= v'(s) decreases instead of being fixed, no surprise as v'(s) is proportional to the RPM).

[MediumRare]

Nice job. Had a quick go over. The one "not obvious" portion is the statement

the derivative s'(t) of s(t) should satisfy s'(t) = V(s(t))

Normally there would be a constant to take care of units, but you picked them well- the constant is 1.

The only other (nit picking) point is that the expression for PCAV is only valid for s >= s_A.

A reality check is that your calculated times are slightly greater than the observed values, which they should be since your linear approximation to the transfer rate is always less than the observed value.

G
(who hasn't done a formal integral for close to 20 years).

[dodecahedron]

i could be wrong, but do i smell TeX here ...?

KCK
i followed most of the calculations (i followed up to, not including, the PCAV section...there i got tired of it )
if you don't mind, i don't understand the purpose of this exercise.
what is it for?
as far as i can see, you're making a linear fit to emprical data (the CDSpeed plot), construct a model based on this and then compute the total transfer time T from the model and compare it with the empirical time.
all this tests is the validity of the model as far as i can understand this, and we know that it's only a rough approximation.

[MediumRare]

KCK:
I've been thinking about this some more and just had a look at the original graphs. I think we get a much simpler expression for the time. With your units, the total transfer time is simply the integral under the curve. The simplest approximation (which you sort of use in your derivation too) is then an approximation with a trapezoid:

Code: Select all

T = 0.5*(V_0 * V_T) * s(T)

Using your values for (V_0,V_T,s(T)) as (22,50,74), (23,50,74), (23,52,74) for the 3 graphs (I've corrected the capacity for the last 2 cases) gives times of (2:03, 2:01, 1:58 ) which is almost exactly the CDFreaks value.

This has to be taken with a grain of salt, though. If we use the true mean speeds shown in the graphs (37.57, 38.45, 39.71), then the integral would be exact (you or dodecahedron can probably name the theorem) and the times are (1:58, 1:55, 1:51). The difference of 5-6 sec. can be attributed to spin-up times in the CD-Speed measurements.

Of course it was a nice exercise, and those can be fun.

Many years ago, I tried to theoretically solve a problem known to all denizens of cooler climates:

How long does beer have to stay in the trunk of the car to cool off to drinking temperature?

My (realistic at the time) boundary conditions were

Code: Select all

    T_beer = 70° F,
    T_outside = -30° F,
    T_drink = 40° F.

I then solved the thermal diffusion equation in cylindrical geometry to derive a formula for T_mean(t). Practical problems arose, though, in finding the heat capacity and conductivity of barley juice. Convection also plays a role and was completely neglected in the approximation. I don't have the notes anymore and don't remember what the result was, but it seemed reasonable at the time.

G

[dodecahedron]

The simplest approximation (which you sort of use in your derivation too) is then an approximation with a trapezoid:

Code: Select all

T = 0.5*(V_0 * V_T) * s(T)

come, come now...it's so long since you did a formal integral, you must have forgotten the formula for the area of a trapezoid

Code: Select all

T = 0.5*(V_0 + V_T) * s(T)

[dodecahedron]

Many years ago, I tried to theoretically solve a problem known to all denizens of cooler climates:

How long does beer have to stay in the trunk of the car to cool off to drinking temperature?

LOL...took me a minute to figure out what you're talking about...in my climate the beer temp always goes up when it's in the car's trunk

[MediumRare]

come, come now...it's so long since you did a formal integral, you must have forgotten the formula for the area of a trapezoid

Oops! I guess I held the shift button too long.

G

[KCK]

First, a couple of clarifications.

For the first CDFreaks picture, I should have chosen s(T) = 72 as for the two remaining ones; then (V_0,V_T,s(T)) = (22,50,72) yields T = 2:07 (instead of 2:10), i.e., all computed times overshoot the actual times by precisely 3 seconds.

In the formula for P-CAV, the first term is the time to reach s_A (computed as for CAV) and the second term is the time to move from s_A to s(T) (computed as for CLV); of course, the formula assumes s(T) > s_A (since otherwise we may argue as for CAV).

Next, some more specific replies.

dodecahedron:

I think the observed concavity of V(s) has two sources.

First, as you observed, the rotating speed decreases slightly over time. BTW, Plextor Premium seems to be good here, especially on the third picture where the rotating speed is almost constant; I've seen much worse pictures for Lite-On drives!

Second, apparently V(s) is concave even for true CAV, at least in my next model (still under development).

MediumRare:

First, I couldn't follow your derivation. Second, if your formula for T (with dodecahedron's correction) were correct, if my formula for T in CAV were correct, and if the curve V(s) were affine, then our values of T should coincide, and thus for V_0 = 1 and V_T = 2 we would have 0.5*3 = ln(2), a contradiction. Third, for (22,50,74) your corrected T = 2664 >> 2. I may be missing something obvious, so please elaborate.

Do you have any idea how CD Speed finds the average speed?

Now some general comments.

As for motivation for such exercises, I wanted to understand what 10-24X CAV means for Q-Check in comparisons with KProbe. The note in the first table of the CDFreaks review

http://www.cdfreaks.com/article/112/4

says "The indicated max speed for CAV is achieved at address 68:00:00", so I started wondering about speeds at 79:00:00, say.

Although I'm making some progress with another model, I still have more questions than answers. In the meantime, maybe you could comment on the following curiosities of CD Speed:

1. The values on the left vertical axis (8x, 16x, ...) are twice the values on the right vertical axis (4, 8, ...), and the graphs of the transfer speed and the rotating speed start at the same point; e.g., for V(0) = 23x the rotating speed is 11,500 rpm.

2. The final point on the horizontal axis is always at least 2 minutes short of the displayed Disc Length; e.g., 74 min vs 77:45:70 in the fourth CDFreaks picture, where I would expect the final point to be 76 minutes. BTW, for one of my discs, CD Speed displays 79:01:35 in Disc Length and the graph stops at 76 min, whereas KProbe reports 79:03:34 and the final tested MSF = 79:03:23.

3. It's not clear whether the Elapsed Time and the final speed correspond to the final displayed length or the larger Disc Length. I don't think the Elapsed Time includes the spin-up time.

4. This needn't be related to CD Speed, but I'm wondering why in the three CDFreaks pictures, for discs containing the same data on different media (pressed CD, CD-R, CD-RW), the initial speeds vary so much (being 22.07x, 23.00x, 23.31x respectively).

[Inertia]

Forgive me for being pragmatic, but methinks, notwithstanding the "simple" linear differential equations and approximations with a trapezoid , this exercise is most easily approached using acceleration formulas.

For example, using the first graph:

speed = distance ÷ time

beginning speed = 75 sectors/sec. * 22.07x = 1655.25 sectors/sec.

ending speed = 75 sectors/sec. * 49.60x = 3720 sectors/sec.

As we know with CAV, when the acceleration is constant the velocity increases linearly. This results in an average velocity equal to the velocity half-way through the data transfer.

Avg. velocity = (starting velocity + ending velocity) / 2
Avg. velocity = (1655.25 + 3720) / 2 = 2687.625 sectors/sec.
2687.625 sectors/sec. / 75 = 35.835x

Obviously, sectors/sec. are irrelevant for the calculation, and the same results obtain just using the transfer "x" speed.

Avg. velocity = (22.07x + 49.60x) / 2 = 35.835x

To calculate total transfer time:

74 minutes / 35.835x = 2.065 minutes = 2:04 minutes

As you see, this agrees exactly with the total transfer time of the graph, and also proves (to my satisfaction) that the average transfer rate of 37.57x shown in the graph is incorrect. This inaccuracy in average transfer rates using CAV holds true in the other graphs as well, and appears to be an overstatement bug in CD Speed.

[cfitz]

I haven't been following this too closely, and I have to admit I haven't looked through your equations. But, I don't feel too bad because the mathematicians and physicists (i.e. dodecahedron and MediumRare) have been giving you good feedback. But I do want to make one general suggestion: don't make things more complicated than they need to be. Here are a few points that may illustrate:

Second, apparently V(s) is concave even for true CAV, at least in my next model (still under development).

True CAV (constant angular velocity) by definition requires that RPM be constant. Otherwise the angular velocity would not be constant. So if you are developing a complex model of true CAV that requires a non-constant RPM, then you are going down the wrong path. Regroup.

Do you have any idea how CD Speed finds the average speed?

I'm not privy to Erik Deppe's actual code, but I strongly suspect it does not use any complex model like the ones presented in this thread. The simplest and most sure-fire method would be to simply divide the total number of bytes transferred by the total time required to transfer those bytes, then scale by 1x = 150 KiBytes/sec. Only multiplication and division required - not an integral or transcendental function to be found.

1. The values on the left vertical axis (8x, 16x, ...) are twice the values on the right vertical axis (4, 8, ...), and the graphs of the transfer speed and the rotating speed start at the same point; e.g., for V(0) = 23x the rotating speed is 11,500 rpm.

The choice as to how to line up the values on the two axes is, of course, completely arbitrary. The two scales are simply drawn on one graph for convenience, and one could choose to line up 8x with 4, 8, 12, 16 K-RPM or any value at all. It would make no difference and have no special meaning. Thus, you can't attach any special meaning to the fact that the values on the left are twice the values on the right. That was just a choice that Erik Deppe made.

The more interesting question is why, given Erik's choice of scales, the transfer rate and rotating speed start at the same point. That is nothing but a happy coincidence (although the fact of the coincidence probably drove Erik's choice of scales). Measure the inner ring of the data track on a burned CD-R (probably easiest to see on a cyanine disc) and you will see that it is about 4.6 cm in diameter, making the circumference 14.45 cm.

The nominal physical linear speed of a 1x transfer rate is 1.2 m/s. We then have:

1x = 1.2 m/s * 1/0.1445 rev/m * 60 s/min = 498 RPM

To the limits of my measurement error, 1x = 500 RPM, and thus the happy coincidence you noted.

And again, nothing but simple geometry and dimensional analysis is required.

4. This needn't be related to CD Speed, but I'm wondering why in the three CDFreaks pictures, for discs containing the same data on different media (pressed CD, CD-R, CD-RW), the initial speeds vary so much (being 22.07x, 23.00x, 23.31x respectively).

Personally, I don't consider that variation to be very significant, and would attribute it simply to the drive reacting differently to the different optical characteristics (e.g. reflectivity) of the different media.

Please don't take my comments the wrong way. I think it is great that you are developing mathematical models to help understand the transfer rate graphs. But make sure to step back every once in a while and see if you can see the forest among all the trees.

cfitz

[cfitz]

Ah, I see Inertia has also been counseling simplicity while I was composing my response. Well, I will leave my post as is to serve as another friendly nudge towards the "keep it simple" philosophy.

cfitz

[dodecahedron]

Inertia, i think you missed a copule of things.

first:

speed = distance x time

i think you got mixed up:

Code: Select all

distance = speed x time

second, since the graph of the speed function V(s) is concave, it's obvious that the "average" speed reported by CDSpeed is (and should be) higher than the algebraic average calculated form the starting and ending speed.

i think this hints at a different question:
what is the real meaning of the "average" speed CDSpeed is reporting? how is it calculating it?
it's definitely not the algebraic average of the starting and ending speeds, nor should it be!

[dodecahedron]

Do you have any idea how CD Speed finds the average speed?

I'm not privy to Erik Deppe's actual code, but I strongly suspect it does not use any complex model like the ones presented in this thread. The simplest and most sure-fire method would be to simply divide the total number of bytes transferred by the total time required to transfer those bytes, then scale by 1x = 150 KiBytes/sec. Only multiplication and division required - not an integral or transcendental function to be found.

well, i certainly hope this is not how CDSpeed averages.
an average of a function f(x) over an interval [a,b] is:

Code: Select all

average(f)=int_a^b f(t)dt / (b-a)

and integrating is not difficult at all - an integral is simply a sum.
so a simple calculation of the intgeral of the speed function V(s) would be:
sum up all the sampled speeds V(0)+V(1)+...+V(s(T)). divide by the total s(T) to obtain the average.

of course we are getting back to the same question:
what is the meaning of the "average" speed and how's it calculated???

[cfitz]

well, i certainly hope this is not how CDSpeed averages.
an average of a function f(x) over an interval [a,b] is:

Code: Select all

average(f)=int_a^b f(t)dt / (b-a)

...

What?!? I would certainly hope that the method I described is how CD Speed and anyone else calculates an average. I think you are falling into the same overly complicated trap that KCK has gotten lost in. You are so focused on the mathematical mechanics of calculating integrals and solving differential equations that you are losing sight of the big picture.

Are you telling me that if a drive can transfer 30,000 KiBytes in 100 seconds that the average transfer rate is not 300 KiBytes/sec (2x) ? I don't care if the drive transfers 300 KiBytes/sec for the whole 100 seconds or 29,999 KiBytes in the first second and 1 KiByte over the remaining 99 seconds or any other combination that works out to 30,000 KiBytes in 100 seconds, the average is still 300 KiBytes/sec. The shape of the curve is irrelevant. Counting the bytes transferred over the measurement interval is all the integration we need to do.

cfitz

[dodecahedron]

cfitz, sorry for my stupid mistake.
the integral under the speed graph = the total number of bytes transferred, in theory at least.
so the two calculations should yield the same result.

you're wrong about my fixation on the mathematical mode.
i'm much more concentrated on the empirical aspect of CDSpeed.
what i suggested was an "empirical" calculation of the integral.
that is what i had always thought the CDSpeed "average" meant, your calculation has never occurred to my mind.

Are you telling me that if a drive can transfer 30,000 KiBytes in 100 seconds that the average transfer rate is not 300 KiBytes/sec (2x) ? I don't care if the drive transfers 300 KiBytes/sec for the whole 100 seconds or 29,999 KiBytes in the first second and 1 KiByte over the remaining 99 seconds or any other combination that works out to 30,000 KiBytes in 100 seconds, the average is still 300 KiBytes/sec. The shape of the curve is irrelevant. Counting the bytes transferred over the measurement interval is all the integration we need to do.

i have to disagree.
i think it makes a very big difference.
it boils down to what we mean by "average speed".
i understand your position, but i do think the shape of the curve is important and of much interest.
of course, in parctical terms, we don't see such "wild" and varying cursves, they're all more or less of 3 simple types. so this discussion is to some extent academic.
but i'm sure you'll grant that the shape of the curse is of some interest, and the average speed is not the entirety of important info.
for the sake of argument, imagine 3 possible scenarios all of which with an average 24x speed: CLV, CAV, PCAV.

i think the inherent question to all of this discussion is:
what does CDSpeed exactly measure, how does it measure it, and how does it display it.
these questions are'nt as trivial as they seem.

[Inertia]

Inertia, i think you missed a copule of things.

first:

speed = distance x time

i think you got mixed up:

Code: Select all

distance = speed x time

See Understanding of the Speed and Acceleration Formulas. I just copied the formula from that site, which is a "Summer Research Program for Science Teachers". It should read speed = distance / time, but I didn't proof read it for accuracy. I guess you just can't trust those science teachers. No wonder our schools are in trouble. If the science teachers can make a mistake in their "speed" formula, Erik Deppe could also have a mistake in his "Average Speed" calculation.

Also, see Acceleration Formulas.

second, since the graph of the speed function V(s) is concave, it's obvious that the "average" speed reported by CDSpeed is (and should be) higher than the algebraic average calculated form the starting and ending speed.

Concave graph?? to my eyes it is so negligible as to be unremarkable and not an issue. Have you considered that the graph may be distorted? As cfitz has explained, either we are dealing with CAV or not. I don't think anyone is claiming to have evidence that the burner manufacturers are lying to us about using CAV because someone imagines they see something different in a CD Speed graph. As I have stated, the fixed RPM of CAV provides constant acceleration in a linear fashion, i.e., a straight line, from the inner hub to the outer edge of the disc. This is a fact, and not a matter of opinion.

i think this hints at a different question:
what is the real meaning of the "average" speed CDSpeed is reporting? how is it calculating it?
it's definitely not the algebraic average of the starting and ending speeds, nor should it be!

As cfitz has alluded, sometimes those that are used to complicated issues may have difficulty with an uncomplicated approach and a simple solution. To my knowledge, there is only one way of calculating an average speed for a CAV data transfer. In the example given, the test disc was exactly 74 minutes. It took 2:04 minutes to transfer the data. 74 / 2:04 is equivalent to an average transfer rate of 35.835x. This average transfer rate was the same rate that was calculated without benefit of minutes in my earlier post, so this is a proof of the average rate. An average transfer rate should be equivalent to a CLV rate that would produce a 74 minute data transfer in a given amount of time. At at (theoretical) CLV rate of 35.835x, a 74 minute disc would be completed in 2:04.

The fact that the transfer was completed in 2:04 minutes is a virtual proof that there can be no "concave" speed curve or RPM change in the CAV transfer. If the provided starting and ending speeds are used, linear acceleration is the only model that fits the completion time of 2:04 minutes. Any variation from constant acceleration would produce a different time.

it's definitely not the algebraic average of the starting and ending speeds, nor should it be!

You are obviously overcomplicating this issue without any real basis for doing so in my opinion. You have presented no basis for this statement other than a strong belief and a resistance to a simple solution.

[dodecahedron]

going back to the original discussion.

something that's been bugging me from the beginning of this discussion.
maybe that's what you meant, KCK, when you hinted at a new model?
anyway, this is the issue of the non-linearity of the speed graph (aside from the fact that it appears, from the CDSpeed plots, the it's not true CAV, since the RPM graph isn't constant).

the problem is that the speed is plotted against the location s and not against time t.
for true CAV the speed v is proportional to the radius r. however, as the data is written on a spiral groove, r is not a linear function of s.

anyway, i don't really have enough time to delve into this (work...) but it seems to me that the relationship v(t) is'nt trivial...

[Inertia]

Here are further proofs of a simple method of finding the total transfer time for a CAV recording when the start and end speeds are given, using the examples from KCK of the first three graphs at http://www.cdfreaks.com/article/112/4 :

Graph #1 (already established, but reiterated)

Average Speed = (22.07x + 49.60x) / 2 = 35.835x

Total Transfer Time = 74 min. / 35.835x = 2.065 min. = 2:04 min.. This agrees exactly with Graph #1 Elapsed Time.

Graph #2

Average Speed = (23.00x + 50.53x) / 2 = 36.765x

Total Transfer Time = 74 min. / 36.765x = 2.013 min. = 2:01 min.. This agrees exactly with Graph #2 Elapsed Time.


Graph #3

Average Speed = (23.31x + 52.45x) / 2 = 37.88x

Total Transfer Time = 74 min. / 37.88x = 1.954 min. = 1:57 min.. This is within one second of Graph #3 Elapsed Time of 1:58.

When the true average transfer speed is known or calculated, the elapsed time for the transfer can be derived as a function.

[KCK]

Here is the first part of the new model. The next part and the more delicate issues raised by cfitz and dodecahedron will be discussed later; right now I just want to explain the magic behind Inertia's examples.

In polar coordinates, the disc track follows Archimedes' spiral:

r = a * Q, ___ (1)

where r is the radius (in meters), Q is the angle (Q stands for the Greek letter theta), and the parameter a determines the track pitch

p = 2 * pi * a. ___ (2)

The length of the spiral

L(Q) = a * Int_0^Q sqrt(1 + x^2) dx

= 0.5 * a * {[Q * sqrt(1 + Q^2)] + ln[Q + sqrt(1 + Q^2)]} ___ (3)

is approximated very well by the reduced length

l(Q) = 0.5 * a * Q^2 ___ (4)

for large values of Q (the ones of interest here). For CAV, Q grows linearly:

Q = Q_0 + 2 * pi * f * t, ___ (5)

where the initial angle Q_0 = r_0/a is determined by the initial radius r_0, f is the rotational frequency (the number of revolutions per second), and the time t is measured in seconds. The distance travelled along the spiral, i.e., L(Q) - L(Q_0), may be approximated by the path length

s = s(Q) = l(Q) - l(Q_0) = 0.5 * a * [Q^2 - Q_0^2]. ___ (6)

We also write s(t) for s(Q(t)). By (5) and (6), we may use the derivatives

s'(Q) = (ds/dQ)(Q) = a * Q, ___ (7)

s'(t) = (ds/dQ) * (dQ/dt) = s'(Q) * 2 * pi * f ___ (8 )

to develop

s(Q) = 0.5 * a * (Q + Q_0) * (Q - Q_0)

= 0.5 * [s'(Q) + s'(Q_0)] * 2 * pi * f * t

= 0.5 * [s'(t) + s'(0)] * t.

Thus

t = s(t) / {0.5 * [s'(t) + s'(0)]}. ___ (9)

We now express this formula in more customary units. For the nominal scanning velocity v_s fixed between 1.2 m/s and 1.4 m/s, one second of disc length (i.e., 75 sectors) takes up v_s meters along the spiral, and thus k(t) = s'(t)/v_s is the current transfer rate in units of 1x. Hence in terms of the measured quantities

T = t / 60 = time in minutes, ___ (10a)

S(T) = s(60*T) / (60 * v_s) = disc length in minutes, ___ (10b)

K(T) = s'(60*T) / v_s = transfer speed in 1x, ___ (10c)

by (9) and (10), we have

T = S(T) / K_avg with K_avg = [K(T) + K(0)] / 2, ___ (11)

where K_avg is the average transfer speed in units of 1x.

Formula (11) is the one used by Inertia.

EDIT: Inserted missing braces in (3), replaced w by f in (5) and (8 ), and b by v_s in (10b) and (10c).

EDIT2: Corrected (10) and a typo in (11).

[dodecahedron]

Here is the first part of the new model. ... In polar coordinates, the disc track forms the Archimedes spiral:

this is exactly what i was thinking!
well done.

like i said, i've no time now to develop the model myself or to check your calculations, but this is the right direction!

[Inertia]

Here is the first part of the new model. The next part and the more delicate issues raised by cfitz and dodecahedron will be discussed later; right now I just want to explain the magic behind Inertia's examples.

In polar coordinates, the disc track forms the Archimedes spiral:

r = a * Q, ___ (1)

where the radius r is measured in meters, the angle Q is measured in radians (Q stands for the Greek theta), and the parameter a determines the track pitch

p = 2 * pi * a. ___ (2)

The length of the spiral

L(Q) = a * Int_0^Q sqrt(1 + x^2) dx

= 0.5 * a * [Q * sqrt(1 + Q^2)] + ln[Q + sqrt(1 + Q^2)] ___ (3)

is approximated very well by the reduced length

l(Q) = 0.5 * a * Q^2 ___ (4)

for large values of Q (the ones of interest here). For CAV, Q grows linearly:

Q = Q_0 + 2 * pi * w * t, ___ (5)

where the initial angle Q_0 = r_0/a is determined by the initial radius r_0, w is the rotational velocity per second (w stands for omega), and the time t is measured in seconds. The distance travelled along the spiral, i.e., L(Q) - L(Q_0), may be approximated by the path length

s = s(Q) = l(Q) - l(Q_0) = 0.5 * a * [Q^2 - Q_0^2]. ___ (6)

We also write s(t) for s(Q(t)). By (5) and (6), we may use the derivatives

s'(Q) = (ds/dQ)(Q) = a * Q, ___ (7)

s'(t) = (ds/dQ) * (dQ/dt) = s'(Q) * 2 * pi * w ___ (8 )

to develop

s(Q) = 0.5 * a * (Q + Q_0) * (Q - Q_0)

= 0.5 * [s'(Q) + s'(Q_0)] * 2 * pi * w * t

= 0.5 * [s'(t) + s'(0)] * t.

Thus

t = s(t) / {0.5 * [s'(t) + s'(0)]}. ___ (9)

We now express this formula in more customary units. For the nominal scanning velocity v_s fixed between 1.2 m/s and 1.4 m/s, one second of length (i.e., 75 sectors) takes up b = v_s * (1 s) meters along the spiral, and thus k(t) = s'(t)/b is the current transfer rate in units of 1x. Hence in terms of the measured quantities

T = 60 * t = time in minutes, ___ (10a)

S(T) = 60 * s(T/60) / b = length in minutes, ___ (10b)

K(T) = s'(T/60) / b = transfer speed in 1x, ___ (10c)

by (9) and (10), we have

T = S(T) / K_avg with K_avg = [K(T) - K(0)] / 2, ___ (11)

where K_avg is the average transfer speed in units of 1x.

Formula (11) is the one used by Inertia.

KCK,

You forgot to start with "In the beginning God created the heavens and the earth.", and work your way forward from there.

Actually, I quite easily plucked the formula and simple explanation from Derivation of Acceleration Formulas.

Specifically, the third formula which starts with:

Also, when the acceleration is constant the velocity increases linearly. What this means is that the average velocity is equal to the velocity at the half-way point (see the picture below), or V(avg) = (V + Vo) ÷ 2

[KCK]

Inertia:

My main point was a self-contained derivation of (6), i.e.,

s = s(Q) = l(Q) - l(Q_0) = 0.5 * a * [Q^2 - Q_0^2]. ___ (6)

The second (minor) point was to derive (9) from (6) via elementary calculations which don't need your Web references.

Of course, (6) can be derived in other ways. It would be interesting if you could find a simpler and/or more illuminating derivation of (6). In other words, this boils down to justifying your God-given statement:

"As we know with CAV, when the acceleration is constant the velocity increases linearly."

In order not to bias your search, I'll save yet another derivation for later!

PS: Full quotes of long posts just add clutter.

[Inertia]

Inertia:

My main point was a self-contained derivation of (6), i.e.,

s = s(Q) = l(Q) - l(Q_0) = 0.5 * a * [Q^2 - Q_0^2]. ___ (6)

The second (minor) point was to derive (9) from (6) via elementary calculations which don't need your Web references.

I believe this exercise in redundancy is colloquially called reinventing the wheel.

Of course, (6) can be derived in other ways. It would be interesting if you could find a simpler and/or more illuminating derivation of (6). In other words, this boils down to justifying your God-given statement:

"As we know with CAV, when the acceleration is constant the velocity increases linearly."

Far from being God-given, I felt that this statement would be so obvious to the technical know-how of this group that I did not expect it to be challenged. I did reference the source in my second post and in my penultimate post. It is a simple mathematical and scientific fact, and does not need justification.

PS: Full quotes of long posts just add clutter.

Yes, and maybe you are getting my point in quoting it. This thread is full of clutter because of the math exercises you are showcasing. As far as I know, nobody has read through and understood one of these turgid dissertations yet. It isn't adding any useful knowledge and seems primarily intended to manifest your math skills.

I for one, will not add further clutter to this thread.

[dodecahedron]

Inretia, even though you've just said you won't post anymore in this topic, i want to add a few comments, some specifically for you, most for anyone interested in this topic

1. i missed your previous post http://www.cdrlabs.com/phpBB/viewtopic. ... 2056#72056 i was in between my 2 posts and didn't see that you posted in the meantime.

2.

I guess you just can't trust those science teachers. No wonder our schools are in trouble.

seeing as i'm a science teacher (math), should i be offended ?

See Understanding of the Speed and Acceleration Formulas.
<snip>
Also, see Acceleration Formulas.

believe you me, i've no need for those references, i know all these formulae by heart! i guess you do get something from a B.Sc. in physics!

"As we know with CAV, when the acceleration is constant the velocity increases linearly."
Far from being God-given, I felt that this statement would be so obvious to the technical know-how of this group that I did not expect it to be challenged.

i quite agree, this requires no derivation, this is obviously true.

3.

Concave graph?? to my eyes it is so negligible as to be unremarkable and not an issue. Have you considered that the graph may be distorted? As cfitz has explained, either we are dealing with CAV or not. I don't think anyone is claiming to have evidence that the burner manufacturers are lying to us about using CAV because someone imagines they see something different in a CD Speed graph. As I have stated, the fixed RPM of CAV provides constant acceleration in a linear fashion, i.e., a straight line, from the inner hub to the outer edge of the disc. This is a fact, and not a matter of opinion.

True CAV (constant angular velocity) by definition requires that RPM be constant. Otherwise the angular velocity would not be constant. So if you are developing a complex model of true CAV that requires a non-constant RPM, then you are going down the wrong path. Regroup.

well, come now. because a manufacturer says so and so, that makes it true??? i can't belive i'm hearing this...
since when have we questioned the accuracy of the CDSpeed graphs? this is the first i see of it in these forums after more than a year browsing through them.
why are all the CLV and ZCLV graphs "really straight" lines, but the RPM not? if the drive manufacturers can make a drive that does maintain a fixed linear velocity, why can't the RPM be fixed too?
if the CDSpeed graph of a CLV and ZCLV is indeed a straight horizontal line, it seems to me that CDSpeed is accurate enough. so if the RPM is not, why are you questioning CDSpeed now?
if you go this way, why trust any of the data from CDSpeed? why trust the starting and ending speeds, the total time etc. etc. ?
i take these graphs at face value. and they all show that the RPM isn't really constant. this is in reference to KCK's comments and mine about non-fixed RPMs. it should be true CAV, but apparently, according to the empirical data supplied by CDSpeed, it's not.

and this could be another possible explanation for the speed graph not being linear.

4.

As cfitz has alluded, sometimes those that are used to complicated issues may have difficulty with an uncomplicated approach and a simple solution. To my knowledge, there is only one way of calculating an average speed for a CAV data transfer. In the example given, the test disc was exactly 74 minutes. It took 2:04 minutes to transfer the data. 74 / 2:04 is equivalent to an average transfer rate of 35.835x. This average transfer rate was the same rate that was calculated without benefit of minutes in my earlier post, so this is a proof of the average rate. An average transfer rate should be equivalent to a CLV rate that would produce a 74 minute data transfer in a given amount of time. At at (theoretical) CLV rate of 35.835x, a 74 minute disc would be completed in 2:04.

The fact that the transfer was completed in 2:04 minutes is a virtual proof that there can be no "concave" speed curve or RPM change in the CAV transfer. If the provided starting and ending speeds are used, linear acceleration is the only model that fits the completion time of 2:04 minutes. Any variation from constant acceleration would produce a different time.

i still disagree about some of the average speed issues.
granted, dividing the total number of bytes transferred by the time to transfer, will give the speed of an equivalent CLV transfer of the same data at the same time. and this is the "formula" for average speed that cfitz has advocated.
however, this most definitely does not proove your calculation that the average speed is the algebraic average of the starting and ending speeds. not does it proove, as you claim, that there is no concavity. and to claim that "linear acceleration is the only model that fits the completion time of 2:04 minutes. Any variation from constant acceleration would produce a different time." is patently a false statement.
i'm looking and the empirical CDSpeed data. the plot is concave. you can't ignore it, i'ts visible to the eye. if i can see it with my eyes, it's significant enough that i can't just ignore it.

5. as to the usefulness of this topic, well, like i said before, i too don't clearly see what's the point.
it's a nice model and so forth. but from a practical perspective, solving it (for the total time,say) and comparing it with the empirical results from CDSpeed, well the only useful thing it does is check the validity/consistency of the model. it does not give us, as far as i can see, any new info that cannot be taken directly from the CDSpeed empirical info.

6. however, it does prod us to think a little more carefully about exactly what's going on inside of CDSpeed, what is it measuring, what is it reporting etc.
so far the most interesting question to me were KCK's questions about the empirical CDSpeed graph:

2. The final point on the horizontal axis is always at least 2 minutes short of the displayed Disc Length; e.g., 74 min vs 77:45:70 in the fourth CDFreaks picture, where I would expect the final point to be 76 minutes. BTW, for one of my discs, CD Speed displays 79:01:35 in Disc Length and the graph stops at 76 min, whereas KProbe reports 79:03:34 and the final tested MSF = 79:03:23.

3. It's not clear whether the Elapsed Time and the final speed correspond to the final displayed length or the larger Disc Length. I don't think the Elapsed Time includes the spin-up time.

so far nobody has responded to or commented about this.

i can add another one of my own:
question: from my (little) experience with CDSpeed, when you do the test the progression along the x axis (location on the disc) is constant with respect to time. i mean the speed at which the test progresses along the x axis is fixed.
however if the reading (or writing) is really true CAV, it souldn't be! because the radius (proportional to the velocity in true CAV) is not linear with the location on the disc. this is what i noted in one of my previous posts.



i guess it all boils down to what you want to get out of the CDSpeed output.
i believe for most of us (all of us except KCK???), we are (were?) all happy to just accept the output as it is, no questions asked and no delving any deeper in...

a small aside, Inertia:
i was sorry to see that your discussion with KCK has "heated up" a bit (not wanting to use a stronger word). i hope you gather from the smilies i splashed throughout that i'm taking all of this rather light-heartedly. hope you do too