Transfer graphs and times

[cfitz]

You're welcome, KCK. Now I will leave it for Inertia to step in and explain why your new model, a simple quadratic when solved for d as a function of h, provides such a terrific match to the observed behavior without any of the messy transcendental functions of before (I suspect you understand now, as well).

Hint: disc minutes are equivalent to distance along the data groove, and transfer speed is a simple linear function of true time in groove (directly proportional, if you set up the coordinate systems to make it so).

cfitz

[KCK]

cfitz:

The fact that quadratics approximate `sufficiently nice' functions closely doesn't mean that the whole world can be described in quadratics alone.

Without going into the issues of mathematical modelling of complex phenomena, let me just recall one basic paradigm. In situations like ours, one frequently derives a fairly simple model via heuristic considerations. The model can be validated in the usual way (get experimental data, identify parameters, compare actual results with predicted ones, etc.). This brute-force approach has obvious defficiencies (e.g., how many tests to run before obtaining satisfactory statistical confidence levels, etc.). Fortunately, in practice one frequently has a more complex model at hand as well; this is usually called an extended model. Then, instead of testing the simple model against reality, one may compare it with the extended model. If both models are close, and the extended one is supposed to be close to reality, this helps in validating the simple model. Further, studying their relations may delineate the possible strengths and weaknesses of the simple model.

I think your comments refer to the simple `constant-acceleration' model. Nothing wrong with that, since my delayed results show that the simple model matches the extended spiral model very well. As I wrote, I'm still struggling to explain these things without getting bogged down in complex notation. It is common for initial writeups of mathematical models to be more complex than necessary; usually things become simpler later when somebody re-examines an existing model to check which features are crucial for obtaining the desired final results. This is the way life goes on, and there is little need for emotional (over)reactions to the facts of life.

Anyway, let's go back to some more mundane questions, which were mentioned earlier.

In one of my earlier posts, I mentioned that the final length displayed on the CD Speed graph can be more than three minutes short of the reported Disc Length (see the fourth CDFreaks picture). This doesn't agree with your explanation that CD Speed `always stops at the last even 2-minute boundary before the capacity of the disc'. Further, also in contrast with your explanation, I guess that the blue progress bar might be intended as a general percentage progress indicator, with no direct meaning in terms of minutes of length covered. The initial two blue rectangles could mean that `something is being tested', so that users don't get worried that nothing is shown. It is not true that two blue rectangles correspond to two minutes; just watch the blue progress bar above 50 minutes. Thus I am not sure that the point plotted at minute x covers the data on disc from minute x to x + 2.

In other words, it could be misleading to assume that CD Speed plots the data as soon as they become available. Of course, only Eric Deppe knows what CD Speed does, but my point here is that we can't really take anything for granted.

Well, our uncertainty about KProbe's Performance | Transfer Rate is similar. When I tested the same disc with KProbe 1.1.19, it gave initial, final and average speeds similar to those of CD Speed. However, it reported the Start Speed before displaying anything in its graph, as if the graph were updated with a delay of one minute. Further, for the disc length being 79:03:34, the final length on the graph was close to 79 minutes (definitely not 78 minutes). More importantly, the graph between 0 and 1 minutes was horizontal. I don't know how to explain this.

Thus we are playing Sherlock Holmes here, but the exercise needn't be entirely vacuous.

On another note, I'm developing a strong suspicion that the yellow line plotted by CD Speed might have relatively little to do with the actual rotational frequency; maybe Eric Deppe is using some formula to compute it from other data. In particular, Eric could be putting too much trust into the formula "initial RPM = half of initial transfer rate", which needn't hold for discs that don't conform with the "usual" scanning velocity.

I guess right now we are more advanced on understanding the true mechanisms of transfer rates than on the software details of CD Speed and KProbe. But we are making progress!

[cfitz]

The fact that quadratics approximate `sufficiently nice' functions closely doesn't mean that the whole world can be described in quadratics alone.

I don't recall ever making such a broad statement. I only said that CAV transfer rate curves for CD's can be described by a simple quadratic.

Without going into the issues of mathematical modelling of complex phenomena...

The constant acceleration model is an exact model based on the physical geometry of the disc, subject to a few very minor simplifications (e.g. it ignores the wobble in the spiral due to the ATIP signal, which your model ignores as well). I would thus tend to disagree with your characterization of the model as "brute force", and could, but won't, argue that it validates and delineates the strengths and weaknesses of the extended model rather than the other way around.

Even allowing for a "brute force" characterization of the constant acceleration model, which I don't agree with, I still find it to be an acceptable approach. Maybe it is just my engineering background biasing me, but I find that starting with the simplest model is generally the most productive route. If it adequately explains the observed behavior, then there isn't any need to go further. Moreover, simpler models tend to be easiest to grasp and thus use to predict further behavior.

Of course, I'm not advocating blind reliance on simple models for complex systems. Even when a simple model does suffice under some conditions, one does have to have a good grasp of the underpinnings of the model so as not to be fooled into using a simple model under other conditions where it no longer applies.

But, in this case the constant acceleration model is quite exact, it is simple because it matches simple underlying physical characteristics rather than because it ignores complex underlying characteristics, and it is quite up to the task of analyzing CDSpeed's behavior.

I'm sorry if you feel that I overreacted in an emotional manner. That was not my intention.

In one of my earlier posts, I mentioned that the final length displayed on the CD Speed graph can be more than three minutes short of the reported Disc Length (see the fourth CDFreaks picture). This doesn't agree with your explanation that CD Speed `always stops at the last even 2-minute boundary before the capacity of the disc'.

If you re-read my explanation, you will see that you have incompletely quoted it, and thus left out the second half which explains the "more than three minutes short" condition to which your refer. Using my explanation and the example you cite, we have the following:

Disc size = 77:45:70
Next lowest two-minute boundary = 76:00:00
Plotted position two-minutes before that boundary = 74:00:00

This agrees with the CDSpeed chart.

Further, also in contrast with your explanation, I guess that the blue progress bar might be intended as a general percentage progress indicator, with no direct meaning in terms of minutes of length covered.

Absolutely it shows the percentage of the test completed, not the minutes completed. Thus, at minute 10 of a 20-minute disc, it will be halfway filled. And this is not in contrast with my explanation, as I am about to explain.

It is not true that two blue rectangles correspond to two minutes; just watch the blue progress bar above 50 minutes.

I never claimed that it did, because I know that it corresponds to percentage complete, not minutes complete, as I noted above. Looking back I can see that I should have made my original presentation more explicit, and I can understand how you could have been confused, but your interpretation that I was equating bars on the progress meter with disc-minutes in the test is incorrect. My conclusions were based solely on the fact that the progress meter increments one time for every 2 disc-minutes worth of data collected, regardless of how many blue bars are displayed with each increment. This is based on careful observation of entire test runs. It is just a happy (or unhappy, depending on one's point of view) coincidence that for a disc of this size one increment of the progress meter happens to have a width of two blue bars, at least at the beginning of the disc.

Thus I am not sure that the point plotted at minute x covers the data on disc from minute x to x + 2.

If you are still not convinced, then perhaps another look at those two snapshots of the beginning of the test will help:



In the fist snapshot, where one increment of the progress meter is displayed (you will either have to trust me that this is one increment or do it yourself and see for yourself), the starting speed is already displayed in the numeric boxes on the right. Thus, it is obvious that one data point has been collected. However, it has not yet been plotted, since two points are needed to plot a line segment.



In the second snapshot, another increment to the progress meter has been added. We now also have a second data point, whose value is listed as the new current speed in the numeric boxes, and a line segment connecting those two points has been drawn. The first point is drawn at the starting speed of 22.90x and the second at the current speed of 23.42x, just as shown in the numeric boxes (subject, of course, to the granularity of the chart, which can not display to four significant digits of precision).

In actual real-time, it took about 10 total seconds from the start of the test to collect these two data points and increment the blue progress meter twice, 5 for the first, and 5 for the second. Five seconds corresponds to reading 2 minutes of disc data at 24x.

Finally, at the very end of the test the blue progress meter is incremented for the final time, the very last point of the graph is plotted, and the end and average speeds are displayed in the numeric boxes all simultaneously and immediately after the last 2-disc-minutes of data are collected (based on timing the real wall-clock seconds).

Putting it all together, it seems quite clear to me that the transfer speed for disc-minutes 0-2 is plotted at 0, 2-4 at 2, and, in general, x to x+2 at x.

In other words, it could be misleading to assume that CD Speed plots the data as soon as they become available. Of course, only Eric Deppe knows what CD Speed does, but my point here is that we can't really take anything for granted.

In general, of course, anything is possible. But it would be quite an odd choice to arbitrarily hold back data on an otherwise real time display and not plot it as it becomes available. Thus, I don't think this is very likely. Of course, if you wish to be a stickler and won't make this reasonable, but admittedly not 100% certain assumption, I feel that you can still reach my conclusion. I think that careful observation of the actual progress of real tests as I observed them and attempted to explain above and in my previous post will lead you to conclude, as I did, that CDSpeed does plot the data as soon as it is available, that it is available at the end of every two disc-minutes, and that the data point for disc-minutes x to x+2 is plotted at x.

Well, our uncertainty about KProbe's Performance | Transfer Rate is similar. ... However, it reported the Start Speed before displaying anything in its graph, as if the graph were updated with a delay of one minute.

It's a little harder to tell with KProbe because Karr never changes his "Spin up" label to "Testing", so I can't really pinpoint exactly when his test is starting, but I think this is the same behavior as CDSpeed. Points are plotted at the end of each collection interval (which defaults to 1 disc-minute in KProbe rather than the 2 disc-minutes of CDSpeed, although you can manually select 2-disc-minute intervals in KProbe), and the first point isn't plotted until the second is also available to make a complete line segment. Also, just like CDSpeed, the speed for the first point is displayed in the numeric box as soon as it is collected even though it isn't plotted until the second point is also collected.

Further, for the disc length being 79:03:34, the final length on the graph was close to 79 minutes (definitely not 78 minutes).

Part of this is due to the default 1-disc-minute collection interval of KProbe. I am guessing that the other piece of this puzzle is that KProbe continues to the very end of the disc to plot one more point of data. Thus, it calculates the speed to be plotted at minute 79 from as much as an interval is left beyond minute 79.

More importantly, the graph between 0 and 1 minutes was horizontal. I don't know how to explain this.

This may be due to the effects of the drive's buffer as I hypothesized in an earlier post. With a one-disc-minute collection interval, it becomes more pronounced. Change KProbe to a two-disc-minute interval, and it will look more like a CDSpeed plot in this area.

On another note, I'm developing a strong suspicion that the yellow line plotted by CD Speed might have relatively little to do with the actual rotational frequency; maybe Eric Deppe is using some formula to compute it from other data.

That is what I suspect also, as I explained in an earlier post directed towards dodecahedron.

I did get a chance to take a look at your averages. My numbers don't quite agree with yours, but do agree quite closely with CDSpeed's. I think this has something to do with the fact that you are using a larger disc size than is plotted on the CDSpeed graph. In your example calculation for the first graph you use 74 minutes for d_T, while I used 72 because that is what is actually plotted.

Here are my figures for a simple average of the discrete samples collected every 2 disc-minutes from 0 to 72, inclusively (I'm a little unclear on your notation, but I think this is what you are getting at with M_I):

Code: Select all

picture  sample avg   CDSpeed avg
---------------------------------
  1        37.55        37.57
  2        38.43        38.45
  3        39.70        39.71
  4        25.24        25.25


To me that is superb agreement, with a maximum error of 0.05%. I don't know how one could reasonably ask for anything better, and I think it confirms my earlier suspicion that Erik Deppe is reporting the sample average as the overall average rather than the true average calculated using wall-clock time.

In my mind we have a very good characterization of what CDSpeed is doing. We know how it calculates the average speed, we know that the average it calculates is wrong, and we know how to fix it (I think we have all said it, but Inertia's formulation may be easiest to understand and implement: divide the number of disc-minutes worth of data transferred during the test by the number of real wall-clock minutes required to complete the test). You may feel that you want to do additional refinement, but I think Seabiscuit is crying "Uncle!" already, and it is time to write Erik an email and explain the bug in his program. I think you ought to take the honors, since if you hadn't started this thread no one would have bothered looking into this.

This is Erik Deppe's email for bug reports:

cdspeed@cdspeed2000.com

cfitz

[KCK]

I didn't have time to digest your reiterated explanation of CD Speed's reporting mechanism. Maybe I'm too hard-headed, but something doesn't fit, so I'll keep thinking about it.

In the meantime, could you explain how the "sample avg" column in your table was obtained?

It might help to clarify some relations between integrals and discrete averages. Let's simplify the notation first.

My model for the graph produced by CD Speed has the following form:

h(x) = sqrt[k_0^2 + (k_T^2 - k_0^2) * x / X]

where x is the disc length (in Minutes) varying between 0 and X, whereas the parameters are those reported by CD Speed:

X = total disc length in Minutes,

k_0 = starting speed in 1x,

k_T = ending speed in 1x.

The mean value of h(x) over the interval [0, X]:

M(h;0,X) = (1 / X) Int_0^X h(x) dx

can be computed analytically:

M(h;0,X) = 2/3 * (k_T^3 - k_0^3) / (k_T^2 - k_0^2).

For n >= 1, consider the points x_i = i * X /n, i = 0, 1, ..., n, and the discrete approximations to M(h;0,X):

M_l(h;0,X,n) = (1 / n) Sum_{i=0}^{n-1} h(x_i),

M_t(h;0,X,n) = (1 / n) {[h(x_0) + h(x_n)] / 2 + Sum_{i=1}^{n-1} h(x_i),

M_u(h;0,X,n) = (1 / n) Sum_{i=1}^n h(x_i).

Note that, by the concavity of h(x),

M_l(h;0,X,n) < M_t(h;0,X,n) < M(h;0,X,n) < M_u(h;0,X,n).

Incidentally, M_l(h;0,X,n) = [M_t(h;0,X,n) + M_u(h;0,X,n)] / 2 is the trapezoidal approximation based on the n+1 points x_i. Yet another alternative is the arithmetic average at all these points:

M_a(h;0,X,n) = [1 / (n + 1)] Sum_{i=0}^n h(x_i).

Next, suppose the actual graph of CD Speed has the form

h_CD(y) = sqrt[k_0^2 + (k_T^2 - k_0^2) * y / Y],

where Y is the final disc length (in Minutes) displayed on the graph. Usually Y <= X - 2; thus the graph of h_CD(y) is obtained by shrinking the graph of h(x) horizontally by the factor Y / X.

The mean values of h(x) and h_CD(y) are the same:

M(h_CD;0,Y) = M(h;0,X).

Similarly, since the points y_i = i * Y /n satisfy h_CD(y_i) = h(x_i), the corresponding discrete averages aren't changed as well:

M_l(h_CD;0,Y,n) = M_l(h;0,X,n),

M_t(h_CD;0,Y,n) = M_t(h;0,X,n),

M_u(h_CD;0,Y,n) = M_u(h;0,X,n),

M_a(h_CD;0,Y,n) = M_a(h;0,X,n).

For the first picture, Average Speed = 37.57, X = 74, Y = 72, n = 37, M(h;0,X) = 37.597478, M_l(h;0,X,n) = 37.223941, M_t(h;0,X,n) = 37.595968, M_u(h;0,X,n) = 37.967995, M_a(h;0,X,n) = 37.549627.

Hence I guess that you used the (n+1)-point arithmetic average M_a(h_CD;0,Y,n) = M_a(h;0,X,n).

In view of close agreement with the Average Speed reported by CD Speed, I'm inclined to make the following bold claim: The minutes displayed on the CD Speed graph needn't be real!

Specifically, one Minute on the graph could correspond to X / Y Minutes of disc length. In other words, the transfer rate displayed at length y on the graph could be gathered at disc length x = (X / Y) * y, or conversely, the transfer rate measured at disc length x could be plotted at length y = (Y / X) * x.

[cfitz]

In the meantime, could you explain how the "sample avg" column in your table was obtained?

Looking at your formulas, I believe what I call the sample average is what you call M_a, the (n+1)-point arithmetic average. It is just the simple average of the speeds at every point where a data sample was collected.

Here is your equation with the values I substituted from the first chart:

h(x) = sqrt[22.07^2 + (49.6^2 - 22.07^2) * x / 72]

There are 37 total points in this chart, every two disc-minutes from 0 to 72, inclusively. In other words there are samples at:

x = 0 disc-minutes, 2 disc-minutes, 4 disc-minutes ... 70 disc-minutes, 72 disc-minutes.

The sample average I calculated is the simple arithmetic average of these 37 sample points at the disc-minutes listed above:

sample avg = ( h(0) + h(2) + h(4) + ... + h(70) + h(72) ) / 37

That's all there is to it. It is just the simplest average we learned in grade school. I realize that this is not the best approximation for the integral of a curve over some interval given a set of discrete samples of that curve on that interval. However, I was not trying to use the most sophisticated integral approximation. I was trying to match what I suspected Erik Deppe is actually doing. And it appears that I was correct in fathoming his strategy for calculating the average, based on the very good agreement I obtained.

In view of close agreement with the Average Speed reported by CD Speed, I'm inclined to make the following bold claim: The minutes displayed on the CD Speed graph needn't be real!

Specifically, one Minute on the graph could correspond to X / Y Minutes of disc length. In other words, the transfer rate displayed at length y on the graph could be gathered at disc length x = (X / Y) * y, or conversely, the transfer rate measured at disc length x could be plotted at length y = (Y / X) * x.

In general I agree with the assertion that the minutes displayed on CDSpeed's graph aren't "real", but only to a degree. I believe that Erik calculates the transfer speed samples by timing how long it takes to transfer 2 disc-minutes worth of data (9000 frames). He then divides the 2 disc-minutes by the actual wall-clock minutes needed to transfer those 9000 frames and arrives at the transfer rate measured as the ratio to the nominal 1x transfer rate. (A curious question is then why he doesn't do this for the entire disc average but instead appears to average the sample values as I described above.)

Anyway, given such a method of calculating the speed, we can see that it is not a truly instantaneous speed measurement. The speed calculated and displayed at a single chart point is actually derived from 2 disc-minutes worth of data, so it doesn't really "belong" to any single point on the chart. It is instead an average over 2 disc-minutes. Thus, the choice of where to plot it is somewhat arbitrary. There is no right answer for all transfer curves, and no right answer at all for some transfer curves. The only constraint that must be satisfied is that the plotted point lie somewhere along the 2-disc-minute interval over which the underlying data were collected. My contention is that Erik chose to plot the speed averaged from x to x + 2 disc-minutes at the chart point x, which is arguably as good as any other choice in that interval.

The way that you are stating that "the transfer rate displayed at length y on the graph could be gathered at disc length x = (X / Y) * y..." makes me wonder if you are assuming that CDSpeed measures the truly instantaneous transfer rate, since you are postulating that data is gathered at a single point and plotted at another point. Are you making this assumption?

cfitz

[KCK]

Yes, your formula coincides with the arithmetic average M_a, although your h(x) corresponds to my h_CD(y). I distinguished h(x) and h_CD(y) to avoid using the same symbol for two different functions, another potential source for confusion. Fortunately all `reasonable' averages of h(x) and h_CD(y) coincide, but it would be bad to average h_CD(y) over [0, X] instead of [0, Y].

My assertion about `unreal' Minutes had other motivations as well. With `real' Minutes, I couldn't understand what was happening at the end of the graph. Even on low-resolution graphs, one can usually see that at the end CD Speed plots something close to h_CD(Y) = h(X) rather than to h(Y) (e.g., h(X) = 49.6 and h(Y) = 49.06 for the first picture).

As for why CD Speed averages over the disc length, maybe for guys such as Eric Deppe the speed averaged over the whole disc provides additional information, whereas for such gurus the `true' average speed is `almost' reported: we now know that it equals the arithmetic average of the starting and ending speeds when CAV works.

And yes, I'm assuming that CD Speed measures a sufficiently close approximation to the true instantaneous transfer rate. Well, I know next to nothing about CD technology, but if Karr Wang is able to work at 1 Second resolutions for KProbe's Write Strategy, then why should Eric Deppe average over 2 Minutes? For instance, CD Speed could be polling the reader for the current length, and when the length is close enough to being even, CD Speed could measure the average transfer rate over a much shorter interval (e.g., by polling for the length again after some tiny delay).

On the other hand, your assumption about `long' averaging intervals of 2 Minutes raises the question on how much the resulting graphs would differ from the graphs based on `tiny' averaging intervals. Not easy, but I'll think about it.

[cfitz]

Even on low-resolution graphs, one can usually see that at the end CD Speed plots something close to h_CD(Y) = h(X) rather than to h(Y) (e.g., h(X) = 49.6 and h(Y) = 49.06 for the first picture).

Are you saying that the last point plotted on CDSpeed's graphs is not the end speed as indicated in CDSpeed's numerical boxes? I don't see that on any of my graphs. The last plotted point always appears to be the same value as the numerical end speed, at least to the somewhat coarse resolution of the chart.

As for why CD Speed averages over the disc length, maybe for guys such as Eric Deppe the speed averaged over the whole disc provides additional information, whereas for such gurus the `true' average speed is `almost' reported

I doubt it. There may be some reason he deliberately chose to do this, but I think it was a just an oversight and he didn't realize that averaging the samples doesn't give the true average for CAV and P-CAV transfer curves.

And yes, I'm assuming that CD Speed measures a sufficiently close approximation to the true instantaneous transfer rate ... if Karr Wang is able to work at 1 Second resolutions for KProbe's Write Strategy, then why should Eric Deppe average over 2 Minutes?

They aren't measuring the same sort of thing. Karr only needs to count the number of C1/C2 errors in 75 frames of data (one disc-second) to get the equivalent numbers of errors per second. He doesn't have to actually time anything.

Erik, on the other hand, needs to time the actual transfer of bytes in order to calculate a transfer rate. And Windows systems don't all implement high-resolution timers that can accommodate accurate measurements of very short intervals. To keep CDSpeed compatible with the widest array of systems, Erik would need to count on a clock resolution of no finer than 55 msec. Using such a timer, he would have a heck of a time measuring the 19 msec required to transfer 1 disc-second of data at 52x, at least with a single pass. Measuring the 2.3 seconds required to transfer 2 disc-minutes worth of data at 52x is much more practical if one is limited to 55 msec resolution clocks, and could be done with a single-pass error on the order of one percent.

On the other hand, your assumption about `long' averaging intervals of 2 Minutes raises the question on how much the resulting graphs would differ from the graphs based on `tiny' averaging intervals. Not easy, but I'll think about it.

It might be difficult to develop a complex model that attempts to account for all the fine points. I'm not sure. But I am sure you don't need to do this unless you want to do it as an exercise of your math skills. Using 2-disc-minute averages instead of truly or quasi-instantaneous speed measurements won't have an appreciable effect on the overall picture. This follows from the linear nature of the CAV transfer curve when plotted against real wall-clock time, and the nearly linear curve even when plotted against disc-time.

As you reiterated in your last post, the true average speed of a true CAV transfer is equal to the arithmetic average of the starting and ending speeds. The same linear characteristics that make this work out also dictate that the instantaneous speed value halfway between the starting and ending times, when those times are measured in real wall-clock seconds, is this exact same average value. Naturally, the same applies to smaller scales as well, so the average speed from x to x + 2 real wall-clock minutes is the arithmetic average of the speeds at x and x + 2, which is also the instantaneous value at real minute x + 1. In other words, for CAV the average calculated over the interval x to x + 2 is the exact instantaneous value at x + 1. The relationship is not exact when plotted in disc-minutes due to the time-dilation caused by later disc-minutes being read at higher speeds as has already been explained, but it isn't drastically off base, either.

For example, on the first chart from CDFreaks the error introduced by reading the curve at the 36-disc-minute halfway point of the test rather than at the wall-clock halfway point is about 7%. That is more than we would like but not horrendous, and it is for a 72-disc-minute span that covers the whole test. The errors will be much smaller over the much smaller span of 2-disc-minutes that I hypothesize is the actual measurement interval.

Visual inspection of the curves indicates that they are very close to being purely linear over a 2-disc-minute span so very little error would be expected by approximating the intervals to be piece-wise linear. A quick back-of-the-envelope calculation of the worst-case error (using your quadratic equation evaluated in the areas of highest curvature at the beginning of the steepest transfer curves) shows a maximum error of about 0.06%. This is below the measurement error and thus not a concern.

Interestingly, this argues, in the case of CAV curves, for plotting the data for the x to x + 2 interval at x + 1 rather than x as in CDSpeed. However, doing so would leave a gap from 0 to 1 minute that undoubtedly would cause many questions. I suspect Erik wisely chose to avoid these questions by plotting at x.

By the way, this is an example of what I meant when I said that simple models are more easily grasped and thus easier to use to predict behavior. Without doing any complex equations I am able to ascertain that the effects of averaging over 2-disc-minute intervals to calculate speed rather than using a true or quasi-instantaneous speed measurement won't have any significant effects on the big picture.

From the tone of your last post, should I take it that you do not intend to write to Erik and explain the bug in CDSpeed? If not, then I will do so.

And with that I will bow out from this thread. I believe it has been worthwhile and you did us all a service by starting it because it has led to clearer understanding of what is going on and the discovery/confirmation of a bug in CDSpeed, but now I have spent far too much time on this and must move on to other things.

Over and out.

cfitz

[KCK]

While I not always agree with all your specific conclusions (at least not initially), I find your remarks to be truly inspiring. Thus another quite long post follows (sorry!), starting with some short responses.

I had been saying precisely what you said later: The last value plotted by CD Speed always appears to be equal to the ending speed reported by CD Speed in "Speed | End".

Your point about the poor resolution of old Windows timers is well taken. In fact timing the transfer of 2 disc-minutes at 52x may lead to a 2.5% error, but fortunately the predicted transfer time is not overly sensitive to the starting and ending speeds.

I couldn't follow your simple model, since it wasn't described precisely enough for me. Hence I developed a `complex' model that attempts to account for your 2-disc-minute averaging. The model is suprisingly simple. Being a result of a quick back-of-the-envelope calculation, it can't be trusted too much; I'll try to validate it formally later. Well, my calculations could be wrong, and I might have missed something obvious in your arguments, in which case I'll be making a fool of myself with this post, but I'll take the risk.

Let Minutes and Seconds denote disc length units, to avoid confusion with time units (minutes and seconds).

Let x_1 < x_2 be two points on the disc length axis (measured in Minutes) reached at times t_1 < t_2 (measured in seconds). Then the average transfer speed (in 1x) over the time interval [t_1,t_2]

H = 60 * (x_2 - x_1) / (t_2 - t_1)

can be expressed via the `true' transfer function h(x) as

H = [h(x_1) + h(x_2)] / 2.

Recall that h(x) has the form

h(x) = sqrt[k_0^2 + (k_T^2 - k_0^2) * x / X],

where x is the disc length (in Minutes) varying between 0 and X, and where the parameters X = total disc length in Minutes, k_0 = starting speed in 1x, and k_T = ending speed in 1x are those reported by CD Speed under `Start Speed', `End Speed' and `Disc Length' respectively.

Using these concepts, I now describe yet another model for CD Speed's graph expressed in 2-Minute average speeds over `real' Minutes.

Given the total disc length X, define

n = floor(X / 2) - 1 and Y = 2 * n,

where floor(x) is the greatest integer not exceeding x. The CD Speed graph runs over the points x_i = 2 * i for i = 0, 1, ..., n, the final point being x_n = Y. Introduce an additional point x_i = 2 * i for i = n + 1. Let t_i be the time at which disc length x_i is reached, for i = 0, ..., n + 1. Suppose the graph corresponds to the function

H(x) = [h(x) + h(x + 2)] / 2.

Then for i = 0, ..., n, H(x_i) is the average transfer speed (in 1x) over the time interval [t_i,t_{i+1}]:

H(x_i) = 60 * (x_{i+1} - x_i) / (t_{i+1} - t_i)

I guess this is close (or identical) to your model. (Note that H(x) could be replaced by a piecewise linear function, having values H(x_i) at points x_i, for i = 0, ..., n.) My way of calculating the final point Y seems to agree with what CD Speed displays.

Unfortunately this model doesn't appear to be very good. Since h(x) is increasing, we have H(x_i) > h(x_i) for i <= n; in fact the differences

H(x_i) - h(x_i) = [h(x_i + 2) - h(x_i)] / 2

are positive and decreasing by the strict concavity of h(x). In particular, the initial and final values H(0) and H(Y) can be significantly greater than the values h(0) = k_0 and h(X) = k_T displayed by CD Speed, whereas Y <= X - 2. Therefore, the `true' final time predicted by h(x)

t = X / {0.5 * [h(0) + h(X)]} = X / {0.5 * [k_0 + k_T]}

can be significantly larger than the time predicted by H(x):

t' = Y / {0.5 * [H(0) + H(Y)]}.

Since I can't post pictures, I describe what happens for the first CDFreaks graph, where X = 74, k_0 = 22.07, k_T = 49.6, n = 36, Y = 72. The graph of H(x) resembles that of h(x), but the differences H(x_i) - h(x_i) are relatively large initially and don't diminish quickly; in particular, H(0) = 22.65837 and H(Y) = 49.86734. The CD Speed Elapsed Time of 2:04 minutes is well predicted by the `true' final time t = 2.065020 = 2:3.9, and not so well by the time t' = 2.000330 = 2:0.02 predicted by H(x).

The situation can be improved by shifting the graph of H(x) to the left by one unit; apparently this is your idea expressed in different terms. Specifically, consider the graph of Y(x) = H(x + 1), i.e.,

Y(x) = [h(x - 1) + h(x + 1)] / 2,

for which Y(x_i) is the average transfer speed over the corresponding time interval [t(x_i-1),t(x_i+1)]:

Y(x_i) = 60 * [(x_i + 1) - (x_i - 1)] / [t(x_i + 1) - t(x_i - 1)].

As before, Y(x) could be replaced by a piecewise linear function, having values Y(x_i) at points x_i, for i = 0, ..., n. Having centered averages really helps: now the differences

h(x_i) - Y(x_i) = [h(x_i) - h(x_i - 1) + h(x_i) - h(x_i + 1)] / 2

are much smaller than in the previous model, because the curvature of h(x) is relatively small. However, some problems remain. First, to find Y(0), we must start reading from the negative length, i.e., 1 Minute before the start of the program (data) area; fortunately, this is possible due to the lead-in. Alternatively, Y(0) could be replaced with the larger value

60 * [(x_0 + 1) - x_0] / [t(x_0 + 1) - t(x_0)] = [h(0) + h(1)] / 2.

As for the end point Y = 2 * n, we could use the (possibly larger) value of n = floor(X / 2 - 0.5), since now we only need Y <= X + 1.

Let's now consider what happens for smaller averaging intervals.

Suppose we measure times t(y_i), t(x_i) and t(z_i) at which disc length positions y_i <= x_i <= z_i are reached for i = 0, ..., n, where x_0 = 0, y_i < z_i for all i, and z_{i-1} <= y_i for i = 1, ..., n - 1. Computing the average speeds

H_i = 60 * (z_i - y_i) / [t(z_i) - t(y_i)] = [h(y_i) + h(z_i)] / 2,

let H(x) be a piecewise linear function with values H(x_i) = H_i for i <= n.

For the two previous models with x_i = 2 * i, we have y_i = x_i and z_i = x_i + 2 in the first model, and y_i = x_i - 1 and z_i = x_i + 1 in the second model. We know already that the second, centered model is much better. Hence we could consider a more general centered model, where the spacings x_i - y_i = z_i - x_i are fairly small initially but may grow at larger disc lengths where the curvature of h(x) becomes smaller. The centering condition can be relaxed to x_i - y_i ~ z_i - x_i without detrimental effects.

Even a non-centered model with y_i = x_i becomes acceptable when the maximum spacing is sufficiently small. Denote by d this maximum of z_i - x_i over all i. Since h(x) is increasing and strictly concave, the differences

H(x_i) - h(x_i) = 0.5 * [h(z_i) - h(x_i)]

may be bounded in various ways. For instance,

h(z_i) - h(x_i) <= h'(x_i) * (z_i - x_i) + 0.5 * h''(z_i) * (z_i - x_i)^2,

where h'(x) is positive decreasing and h''(x) is negative increasing:

h'(x) = (k_T^2 - k_0^2) / [2 * X * h(x)],

h''(x) = - (k_T^2 - k_0^2)^2 / [X^2 * h(x)^3].

In particular, even the following crude bound

h(z_i) - h(x_i) <= h'(x_i) * d < h'(0) * d,

shows that H(x_i) approaches h(x_i) quite nicely for all i when the lengths of all the averaging intervals are small enough.

Finally, if you wish to inform Erik Deppe about the bug, please go ahead. I am not too optimistic about his responses.

[MediumRare]

KCK- have a look at this tool. If you use TeX, this could help you to produce more legible equations and make it easier for me (and you probably) to read your posts.

TtH: the TeX to HTML translator: http://hutchinson.belmont.ma.us/tth

G

[dodecahedron]

TtH: the TeX to HTML translator: http://hutchinson.belmont.ma.us/tth

GREAT! extremely cool!
thanks

[KCK]

MediumRare and dodecahedron:

I just spent a couple of hours on testing TtH and then converting my previous post into HTML. Well, TtH has its share of glitches, but the output looked much more readable than the initial text version.

However, in the Reply window, I have `Options | HTML is Off'; I guess this means that I won't be able to post my HTML code.

Let's just say that I'm a bit frustrated...

EDIT: I tried posting some HTML output from TtH. When I viewed it later on the forum, the HTML code was not interpreted, as if the contents were treated as a text file.

[MediumRare]

EDIT: I tried posting some HTML output from TtH. When I viewed it later on the forum, the HTML code was not interpreted, as if the contents were treated as a text file.

I saw that earlier. Actually, I was afraid that this might happen- the thought came to me just after I made the post, but I then left it because I figured this info (TtH) is interesting in its own right.

G