Topic: Edirol R4 digi in....does it resample or not?

[ellaguru]

hello all...just about to pick one of these fine units up and im curious if the machine resamples on digi in or not?  i cant seem to find the answer in any threads around here.  is it a case (like going digi in on the micro tracker) where the recorders setting just need to be the same as the input stream?

thanks again

chris

[page]

hello all...just about to pick one of these fine units up and im curious if the machine resamples on digi in or not?  i cant seem to find the answer in any threads around here.  is it a case (like going digi in on the micro tracker) where the recorders setting just need to be the same as the input stream?

thanks again

chris

I swear it resamples the digi-in (and disables ch3&4 when it takes the digital signal). There was a guy in town who had one for a while and he never used the digital signal as a result of that when he did 4ch recording.

[JasonSobel]

yes, the original R4 does resample the digital input.
However, neither the R4pro and the R-44 resamples the digital input.

[SmokinJoe]

Everyone seems to agree that it resamples.  A lot of people seem to think this is inherently evil.  I think it's much ado about nothing, and potentially advantageous when it comes to reliability.  It has become an emotional issue resulting in flamewars which I hope we don't need to repeat here.

What it means in practice:

• you can't lock on to an upstream clock.  If you are want to clock-sync multiple decks together, you can't.
• you can accidentally (or on purpose) set the R4's recording rate at something other than the upstream sources output rate, and it will politely work without complaint, for better or for worse.  You won't get "slow files" or "chipmunk sounding files", but I suspect you might get aliasing, so it's best not to do it.
• if you get a "glitch" in the digital signal, it will result in a "dropout", in other words, a flat-line in your wave file.  Some devices "skip" (you hear that time is lost but have no idea how much - like an H120).  Some devices will "lock up" (aka MT).  None if it is good, but I find a dropout is easier to live with (or patch) than a skip or lockup.

As previously mentioned, if you use digi in, you can only use 2 channels.  If you already own a mini-me or other digi-only preamp (which I think the OP does), it's probably better to look at an R44 or DR680 which allows multiple modes.   If you run analog in (which I do), it's not really a problem.

One thing the older R4 has over the newer boxes is the large capacity hard drive.  For weekend festivals, I prefer a hard drive that will hold the whole weekend rather than stressing over when to swap SD/CF cards.  If you don't do festivals, then I guess it doesn't matter.

[ellaguru]

so, by using the r4 to do some DAT > wav  transfers all should be just fine?  im not too sure the difference between a digi transfer with the r4 and a recording with the wrong header info. 

[OFOTD]

The R4 resamples the digital signal.

The R4 Pro and R44 have bit perfect streams.


So transferring your DATs to the R4 means it WILL resample if you are using the digital connection.    Some people care about it and some people don't.   For me I want the signal to be exactly as I recorded it, period.  Can't do that with a R4.   

[fmaderjr]

Also, if you are going to use it as a recorder after your DAT project, I think it is generally agreed that an unmodded R-4's pres leave something to be desired. I believe most members here running R-4's have modded versions.

Many users here have found and unmodded R-44's pres to be just fine.

[SmokinJoe]

so, by using the r4 to do some DAT > wav  transfers all should be just fine?  im not too sure the difference between a digi transfer with the r4 and a recording with the wrong header info.

Yes, "by using the r4 to do some DAT > wav  transfers all should be just fine."  There is debate that it may be 99.99% perfect on an R4 versus 100% perfect on different deck, but it should sound fine to your ears.  You shouldn't have to worry about getting bad header files... it's not going to give you a file that's really slow, or really fast, like playing a 33 rpm record on 45 rpms, etc.

Are you intending to play back a 16/48 DAT into an R4 and have the R4 digi-in set to 44.1k for CDs?  It will work and you won't get funky headers, but I'm just not sure that it's a good idea to purposely mismatch the clocks.  I would suggest you set the R4 to match the DAT and then use computer software to resample the 48K to 44.1K.

[OFOTD]

There is debate that it may be 99.99% perfect on an R4 versus 100% perfect on different deck, but it should sound fine to your ears. 

Not sure which 'debate' you are talking about but according to Edirol/Roland and as proven here there is no debate to be had.  The R4 does resample, period.  What you put in digitally is not what you are getting out.

The resampling is a deficiency that the R4 has and one reason why the R4 Pro and R44 are both bit perfect.

Justify the difference whether big or small but the facts still remain that there is a difference.   

[SmokinJoe]

Apologies OFOTD.

I realize there is no debate about the resampling, it's there.  And if I had the kind of money tied up in high quality A/D's that you have, I'm sure I would want things going into my digital bit-buckets as accurately as possible with respect to what my A/D put out.  I respect that entirely, and don't mean to belittle that.

You are right, the debate is entirely in the realm of "how much" and "does it matter"?  And I really didn't want to get into that, but I feel challenged.  I'm not an expert, but I have enough technical knowledge to draw my own conclusions.

My particular V3 and my particular R4 do happen to align significantly better than 99.99% every time I've checked, and I've checked a few times (a ratio of 1.0 +/- <.0001 is 99.99%, and I generally get .00001 which is an order of magnitude less).  On a particular day... it *could* be that the clocks randomly align, and then accuracy would be 100%... not likely for long, but it could happen.  So I consider worst case accuracy 99.99%, typical accuracy 99.999%, and hypothetical best case 100%.

Just because someone has a "bit perfect" bit bucket like an R44 doesn't mean 100% accuracy.  Some digital protocols like TCP/IP have checksums and retries, etc., to make SURE the data is correct.  S/PDIF does not have these, so if there is jitter or noise on the line, the hardware implementer is left to "do the best it can with what it's got" which I suspect on most consumer class boxes is less than stellar, so the result may be less than 100%.  For those who use AES, AES has a CRC byte, which is a checksum to detect errors.  I haven't studied AES enough to figure out if it can correct the errors, probably it can, but it's pretty clear that S/PDIF can't.   If you have an R4 pro, or SD744 and run AES in, you have a much better chance of 100% than someone with S/PDIF into an R44.  At any rate, there is plenty of opportunity for a "less than perfect transfer". So I consider best case accuracy 100%, but no certainty of that, and I'm not sure how much less.  Now to be fair, the R4 could also suffer this same S/PDIF inaccuracy.  I've seen quite a few digi dropouts on different decks which are audible, so I would predict there are many many more that I can't hear, which makes me speculate the error rate is a significant.

So we have two cases...
a) The resampling R4 which is probably 99.999% accurate, and almost surely no worse than 99.99% and hypothetically as good as 100%.
b) The "synchronizing R44" which is "probably a little less than 100% but I don't know how much".
The traditional statistical tool for determining if something is "significantly better" is a Student's t-test.  I have thought about doing a test where I run a known sample (a contrived wave file from computer generated data) into my R4 and into my buddy's R44, each 25 times, then analyze the output files to come up with an accuracy factor and run it through the t-test math.  You know what?  I decided it's too much like work, and I never bothered.  And as far as I know neither has anyone else.  So no one really knows if the so called "bit perfect" boxes are any more accurate in the end or not, everyone just assumes they are.

So.... I think my previous statement "There is debate that it may be 99.99% perfect on an R4 versus 100% perfect on different deck" may be overly simplistic, but I didn't just pull it out of my ass... it has technical rationalization.  And I think it's a damn shame the people who own "bit perfect" boxes belittle the hell out of other people's gear, to the point where the folks who own "non-bit perfect" boxes they feel like second class citizens and spend hundreds of dollars buying new boxes just so they don't feel like second class citizens any more.  I've seen it happen and I think it's ridiculous.

So Yes, the R4 resamples.

[ellaguru]

Also, if you are going to use it as a recorder after your DAT project, I think it is generally agreed that an unmodded R-4's pres leave something to be desired. I believe most members here running R-4's have modded versions.

Many users here have found and unmodded R-44's pres to be just fine.

the one im after has the busman mods  + i run sxm2 in front too...

[it-goes-to-eleven]

It would be interesting to try and do some correctness analysis...  Though where resampling is involved, like the r44, the result is almost certainly somewhat hardware dependent.   Meaning the easiest test, a computer output to the r44, would not necessarily tell you about dat > r44 performance.  And each sample rate and bit depth could have different accuracy.

Once upon a time, I purchased a pcimcia audio card and did some correctness testing. I found it resampled, and I returned it.

It's one of those boring but important things, where we really just want it to be "right".  And in the case of preserving old DATs via transfer, you really don't want to lose anything.

Back when I was doing more digi, I wanted to write an audio analyzer that would scan the audio for out of range data.   Ultimately, I think I said "f this!" and stopped using bit buckets. Many audio programs have noise detection routines, but I don't know of any optimized for detecting digital transfer issues.