Will SQ between HDD VS SSD VS RAM be measurable for digital audio?

[Windows X]

I've been curious with this for a while if signal from AES/EBU can be measured to differentiate between HDD VS SSD VS RAM. I'm gonna measure them all through digital recording without passing D/A so there will be no fault in DAC (Though I don't really know how  DAC can plot graph with fault like that.) It would be nice if we can write graph from software alone so we can avoid interferences outside numeric digital domain. I hope effects from inteferences won't be too great to make digital recording through AES/EBU uncomparable.

Has anybody ever try to make measurements on this? I'm going to measure with this configuration

sender: optimized Windows 7 system using Weiss INT202 (I wish I could get better audio interface with AES and word clock sync though)
receiver: optimized Windows 7 system using RME HDSP-AES32
interface: AES/EBU
software: Xonar 8 with WASAPI digital recording optimized for clocking

I will use linear PSU for feeding computers with value grade to sender and audiophile grade to receiver. Right now I'm thinking about proper methods to measure because last time I tried using truncate silence in audicity and foundout they have different samples. If digital domain should always be the same and really reliable, they shouldn't have any difference with same effects applied. While I believe can't be that ideal, it seems some people don't.

Some of you may curious why Windows 7 not Mac for this.....I would say by kernel design and architecture, Windows 7 is superior to Mac when it's configured right.

[PeterSt]

Hi,

Although the question (or quest ) is good within itself, the result is also too obvious to ever bring in practice. I mean, as an explicit test.
So, if I understand you right this is just about the "normal" check for all being bit perfect, and while I hardly can believe myself it is (regarding the huge differences), it just is. I have done this too many times for "random" situations just to know, and besides me doing it, many others did - even on explicit request from myself.
Again, if I understand you correctly.

Keep in mind that with my mentioned "random" I refer to various situations throughout time I did that, and although for myself that will have been on the same physical system, OS would not have, spinning disks will have turned into SSDs, and no, with a RAMDisk I coincidentally never tried. But again there will be no difference to be measured.
Btw, for my own tests I do not refer to HDCD lights or DTS tests or anything, but normally comparing the "recorded" file with the original data, byte for byte.

through digital recording without passing D/A so there will be no fault in DAC (Though I don't really know how  DAC can plot graph with fault like that.)

Well, I even did that. Some results are in this topic : Measuring XXHighEnd ... . But of course this was nothing about comparing HDD/SSD/RAMDisk, but you can bet the differences would have shown. If you hear it (and we do) it shows with this "measuring" means. Everything shows. If a knot in your LS cable makes an audible difference, it will show too. If it doesn't show, the knot doesn't work.

I hope this can do for an answer ?
Regards,
Peter

[Windows X]

This quest is for making concrete proof for non-audiophile people to understand if changes from computer side like storage/playback engine/etc. can cause significant difference in audio output. I tried showing your graph to them but they said that DAC error could cause that.

It would be nice if you can do measurements again without relying on D/A so digital perfectionist elites can accept that as matter of fact. Test can be done by either RME HDSP AES card or Weiss DAC202/Vesta/AFI1. Adding word clock sync from Antelope or Esoteric clocks would be nice.

[PeterSt]

Well, that at least sounds very open, and foremost honest. So (and maybe again) nothing against the idea. But how can e.g. I do that, or anyone else for that matter ? I don't have the particular equipment, and maybe nobody has. Maybe you ?

I sure could help you to set up such a test. It is not *that* difficult, but it needs some guidance.
If you are not into this, just don't respond. If you are, let me know by email or PM. Nobody will know the difference;
I guess you know my objective (proceed on all this stupid stuff), and for you ? sometimes it is hard to tell. But I hope you know I am open to anything with positive sense, so proceed how you think it's good or best.

Peter

[Windows X]

At the moment I have RME HDSP AES-32/Weiss INT202/Antelope Isochrone OCX-V

The issue is I don't really think Weiss INT202 is reliable enough as it doesn't support word clock so I'm trying to get my hands to DAC202 on loan but can't find any right now. The best I can come up with is using INT202 as sender and RME as receiver with masterclock for best digital recording. I mainly wanna compare between storage like HDD/SSD/RAM using Sonar 8 producer trial for recording.

You can list me what to record and I'll send you recorded wav file for making analysis and show the result.

[PeterSt]

If you trust me on creating the results ... I will be happy to do that.
But let me think of how to tell you what to do exactly to create (record) the files in good fashion in the first place.

but

The issue is I don't really think Weiss INT202 is reliable enough as it doesn't support word clock

Let's say your assumptions are correct. But let's also assume that I say it won't matter anyway. What would it tell you if I would come up with "no (bit) changes in anything" ? Wouldn't it be the best result you can ever obtain ? I'd say you can skip the remainder of the test to begin with (with such a result). Or ? (and please don't hesitate to explain further while both you and me are in a good mood ).

[Windows X]

My only concern is bit transparency check of recorded files without changes after each playback. To ensure system's accuracy in measurements, I want to record the same experiment 3 times and make sure they can pass bit-transparency check. While I'm not certain if that could actually be possible, I'd like to make things as good as I can.

For most computer geeka, I know they wouldn't even bother as long as it doesn't mess with bit-perfect thingy. If you think INT202 -> RME AES + Antelope clock recorded by Sonar 8 with configured WASAPI digital recording optimized for clocking is good to go, I'll setup test equipments in next 24hrs.

[PeterSt]

Ok, good. For now I hope this descriptoin will do :

Take a player of which it is guaranteed (!!) that it will use WASAPI Exclusive Mode for output. XX comes to mind (it won't do otherwise (Engine#3) but Foobar is ok too). XX Engine#4 also ok.

I don't know Sonar, but try to set a treshhold on "start recording" of a value -> the lowest (which is just 1). So, preferrably do not start recording because you press a record button; recording should start automatically (after playback started).
Next (or earlier of course), please choose a track which to you idea immediately starts with some slam. So not "easy", but with some burst of (high transient) sound. This is necessary to find the alignment within 30 minutes on my side ...

FileMail me the resulting files and the original of course to "sales" at "you know". I will compare the files and produce the results.

Side note : if you can't use WASAPI for recording while using the Exclusive Mode means for playback, something is wrong. It can be done ... I know.

I'm off now. Good luck !
Peter

[Windows X]

Thanks. I'll take your advice in my consideration for making quality recording. Hope it won't take long to get used to making good ones. It'll be WASAPI exclusive with bit-perfect guaranteed playback.

Besides SSD VS HDD VS RAM, do you want me to make anything else?

[PeterSt]

Only if this first set shows differences.

It'll be WASAPI exclusive with bit-perfect guaranteed playback.

Doesn't this sound funny in this context ?

[PeterSt]

Are you ok ? Can I help ?
I hope you didn't stay awake for 32 hours in a row to get it all going ...

[Windows X]

There're some difficulties here. my OS is heavily trimmed down so most pro applications didn't work like sonar, i-sound, etc. Due to various circumstances, the best I can come up now is recording through MME with Audicity using 2ms recording latency and ram buffer.

I'm testing Audicity right now to see if it can work for this project.

[PeterSt]

Hmm ... My OS is (I think) trimmed down so far it can't be any further, and I just tried GolWave, which works.
I don't know whether you know it, but it is free for a couple of 1000 "clicks"/actions etc.

the best I can come up now is recording through MME

I can't be sure where this restriction (MME) comes from, and on the other hand I can't imagine where a single restriction could be if I'd use GoldWave (but what's the difference) and the normal means I would use for playback (which obviously would be XX).
Does that help ?

[Windows X]

I've finished my recording using Audicity @1ms latency. MME is similar stuff to ASIO but not well supported by most manufactures but still be counted as direct host like ASIO/WASAPI. I can still record @1ms latency so it should be OK for RME's MME. I'm recording on heavily modified music server so taking parts out and in again requires a lot of time and effort.

Anyway, Audicity seems good enough for getting jobs done right. I can hear veiling sound from hdd 2.5, clearing sound in ssd, more revealing details in ramdisk files. I'm uploading it right now. Will send you PM when done.

[PeterSt]

Ok, good.

One question for now : How do you get (RME's) MME running on W7 ? I thought this wasn't possible ...

[Windows X]

That's weird to me too. Maybe it's ASIO under MME name lol.

[PeterSt]

Hey, nice. Didn't know that. Thanks.
(DLing the first one now )

[PeterSt]

Btw, you may not think of it, but I like to have the original file also. Not only for when things differ, but merely because I will be able to eliminate *that one* for having some offset (while your recordings always will have).

[Windows X]

Sent. It seems someone's trying to measure this by using floating point rounding error in http://twitpic.com/3ylv70/full. What do you think?

[PeterSt]

Was this last one the original ? (it has the same name as the first one).

Will this be all, or do you have more ? (this seems the "hdd" test)

Looking at the link now ...

[Windows X]

nah. I included original file in so it'll be bigger. Anyway, about posted pic, it's between HDD and RAM. I don't understand why he did floating point rounding error comparison. It's fixed 16 bit wav which sounds irrelevant to me.

[PeterSt]

I've been staring at it, but I can't think of a clue.

Will this be all, or do you have more ? (this seems the "hdd" test)

Sorry, I confused you with this; I didn't unpack things, and now I did I see what's all in there.
But now I don't understand ...

You sent me two RARs. Should I only use the second ? (you just sent that again, but now including the original ?)

[Windows X]

Use the second. It has original file and you can read radme.txt inside for more information.

From excel chart, all I could think was dithering floating point bit to fixed bit ones. Dithering sounds kinda strange for measurements no matter how hard I think about it. It ruined my effort for using high quality audio interfaces and direct recording at very low latency.

[PeterSt]

Sorry, I didn't see the readme. Still not.

Ok, I compared the original to the hdd one. They are NOT equal.

All I can say at this moment is that it looks like dither to me (totally unrelated to your dither from your last post btw).
The off-values are the minimum (decimal 1).

So, or this wasn't bit perfect playback, or this wasn't dithered recording. So please think about the latter (check for Audacity settings) IF :

... If you are 100% sure that MME for W7 is bit perfect in the fisrt place. So, back to that subject, although I didn't know MME could exist for W7 (Vista), I'd sure say that it won't be bit perfect. That is, when something like DS is used for playback. Vista/W7 just can't, no matter MME does it ... for XP. Just my opinion because I don't know anthing better.

About that dither : it is also good to know maybe, that no soul on the globe ever came up with the "dither" XP applies, when all should be as bit perfect as could be, but still is not. But, I did, and I am fairly sure I am right. Btw, notice that right in the middle of Amir what's his name, I *suggested* it to be dither, and he never denied it, or just doesn't know (he was from Vista Audio dev., maybe not XP).

Well, it is this what I'm seeing here.

Can you tell me, what is the problem (or "your" problem) with using XX for playback here ? I mean, I don't think you do ...

Quite some suggestions, and I could be wrong on a few of them.

If you are fed up with it at this moment, just tired, slammed by disappointment, just hop off for now. We can proceed with it later. But let me know. I am not long here myself as well for today (one more hour maybe).

[Windows X]

As my machine is optimized for J River now so I'm using it with WASAPI Event Style (Exclusive). It should be bit-perfect so my guess is recording program that didn't record it right. I'll try your Gold Wave next week so please give me screenshots of your recommended settings to test.

[PeterSt]

give me screenshots of your recommended settings to test.

Nice one ... but I'd have to set it up myself for that. What I recall of it, all is ok by default. Only when you want to record in higher than 16/44.1 things have to be done.

But why wouldn't Audacity be able to do it ? I have it but hardly ever use it. Just look for some dither setting. If you found it, and it's not on, then start wondering what may be happening.

Lastly, I think I can tell you that JR is not "bit perfect" by default (or "always"), but, not sure. Foobar is. XX is too.
IOW, don't think WASAPI is "bit perfect". It is hardly related. It's the Exclusive Mode doing that, and you won't be able to tell so easily. So, I sorted it out, and only from Foobar I dare to tell that it is so in ALL cases, or otherwise it won't play.
Notice that already the fact that your are recording at the same time, can imply that Exclusive Mode can not be used. You could check forever, and get crazy. Foobar will just give you the message it can't play. As will XX.

Don't get mad.

[PeterSt]

WASAPI Event Style

Totally unrelated. But, for JR guys it may say something. Similar to me calling something "straight contiguous" while you will know what I mean with that. JR guys won't.
But "event style" normally is just some opposite of a timer and "polling".

[Flecko]

Sent. It seems someone's trying to measure this by using floating point rounding error in http://twitpic.com/3ylv70/full. What do you think?

Do you know how this was created? The measured error seems more ore less the same. 0.000031, and 0.00003 (with different signs and addition of them). So, it is systematic but looks very strange. Why should the data being rounded? Just if the bandwidth is limited or not? and also that rounding is strange. 0.000024->0.000028?

[PeterSt]

Hi Adrian,

This was my first thinking too. But there is no error there. Look at the right side of that spread sheet, notice the offset mentioned, and then look at the error. There is none ...

Peter

[ipats]

Hi, i'm who make the spreadsheet. let me explain.

First,

rounding is strange. 0.000024->0.000028?

It's binary rounding, not decimal. I guess that the audio softwares work in floating-point, and may also the sound hardware. So, when it convert sample to PCM integer, it need rounding and also dithering. I didn't round any sample, I used the original sample value from files I got. So, I have no clue which process the rounding take place. All I did is find the offset and compare those files.

I also make another comparison, in hex editor. You can see it here: http://twitpic.com/3ymmoy/full (see the highlight in each window)

They're bitstream from files I got, I didn't alter any of them. As you can see, there're offsets, so the files are difference when compare with foobar2000 or something like that. But when the samples were shifted to be the same offset, they're almost the same.

You can see that the difference between sample values in files occur only +/-1 or +/-2. So, I think it's must be a rounding & dithering. As I mention above, I have no clue which process did this because I didn't the one recorded these files. Maybe the player, recorder, hardware, driver or anything else...

PS: You can check my comparison with the files you have, I didn't edit them.

[PeterSt]

This was my first thinking too. But there is no error there. Look at the right side of that spread sheet, notice the offset mentioned, and then look at the error. There is none ...

Ok, so this was totally wrong from me. I compared that right side with the RAM column. But the right side *is* the RAM column.

PS: You can check my comparison with the files you have, I didn't edit them.

You guys (Window X and ipats) have easy talk here. But I guess someone wanted to tell (at least to me) that you (ipats) and me are doing the same thing on the same files ? Language stuff I gues. Well, then it is good we have the same results (or the same conclusion) ...

Window X, I think I may know of an easy way to check whether your recording dithers, or whether the playback is not bit perfect for whatever reaons; it only will not exclude the both being wrong :
Record silence.
So remove that treshhold I was talking about, and just press "record". A few seconds will be enough. Now the file should contain all the same data ... If not, something is going on on that part of the process.

[Flecko]

rounding is strange. 0.000024->0.000028?
It's binary rounding, not decimal. I guess that the audio softwares work in floating-point, and may also the sound hardware. So, when it convert sample to PCM integer, it need rounding and also dithering. I didn't round any sample, I used the original sample value from files I got. So, I have no clue which process the rounding take place. All I did is find the offset and compare those files.

I think this is most interesting. So if the binary to floating point conversion could be avoided, then we could translate the binary data to PCM without loss of information.

[PeterSt]

Very far (sought) you are correct. One problem : when there is no reason to convert to float a player should not. Now, if *this* suddenly starts to be a reason players are not "bit perfect", well ... that would be new. Or at least to me it would be. So, now it's not the OS doing anything, but a stupid player is ? it very well could be. Also, don't ask me to what degree this may influence the HDCD light; it just might stay on ... I don't know. I don't think the DTS test will pass though.
I don't have the experience on this really, because I always check the files themselves (like I did it here). ipats is actually the first one I run into who does this too. Maybe because he was asked to (by Window X), I don't know. So, all I know is that everybody always comes up with that HDCD light (DTS is more old fashioned).

But why not ? If some player feels that it's a good think to start to convert to float first because of *possible* volume or other DSP stuff, I guess it will come down to this, yes. If this really happens ? Maybe JR does it like that.

One thing : XXHighEnd most certainly does not, and it is therefore bit perfect (but don't use upsampling of course). I always checked it myself too, although it is somewhat longer ago by now. In the very old days I used Foobar to check for bit perfectness - not to check Foobar, but to check the OS. At least back then all was OK on the Foobar side.

So, I don't think the chance is very high that players make this fault, already because people would still use the DTS test here and there. Otoh, JR-Event etc. is rather new, so, who knows ...