Topic: Edirol R-44 - Solid State 4 channel recorder

[Rick]

So I decided to e-mail Edirol about the resample issue and got this repsone:

While the R-44 is not yet available and technical data is not yet
published, our team in Japan informs me that the SPDIF input of the R-44
will be sample accurate and will support 24-bit.

Best Regards,

Ted Rosen
Roland Systems Group

I got this response awfully fast though. I've got my doubts about it. Who knows if this guy really knows what I'm asking. I'd imagine the guy Dave talked would know better, but who knows.

[OFOTD]

but who knows.

^^^ the key three words.

FWIW, I got the same response when I bought my original R4.   Lots of things could be fact or non-fact.  Just have to have one in hand to confirm things.

For me the measuring stick is the price.  While by appearance it looks great but with both the R4 and R4 Pro still being marketed I can't imagine that they'd undercut two current products at higher price points.

...but who knows

[Rick]

For me the measuring stick is the price.  While by appearance it looks great but with both the R4 and R4 Pro still being marketed I can't imagine that they'd undercut two current products at higher price points.

My question is, is the resampleing of a digital inputs a product of bad design or cost cutting or both? I think both the iRiver 120/140 and MicroTracker have been proven bit accurate but both are on the cheaper end of recorders… the iRiver wasn’t even primarily designed as a recorder.

[OFOTD]

For me the measuring stick is the price.  While by appearance it looks great but with both the R4 and R4 Pro still being marketed I can't imagine that they'd undercut two current products at higher price points.

My question is, is the resampleing of a digital inputs a product of bad design or cost cutting or both? I think both the iRiver 120/140 and MicroTracker have been proven bit accurate but both are on the cheaper end of recorders… the iRiver wasn’t even primarily designed as a recorder.

I'm sure there are experts here but I always understood it to be the chips used in the gear.   I assume <---- that they cut costs by using lesser priced chips.  Also I can't imagine most of their client base is as nit-picky about this issue like we are.

[Rick]

I assume <---- that they cut costs by using lesser priced chips.  Also I can't imagine most of their client base is as nit-picky about this issue like we are.

And iRiver and M-Audio don't care for a sub $300 machine? Or did they stumble upon cheap chips that are bit accurate.

[OFOTD]

I assume <---- that they cut costs by using lesser priced chips.  Also I can't imagine most of their client base is as nit-picky about this issue like we are.

And iRiver and M-Audio don't care for a sub $300 machine? Or did they stumble upon cheap chips that are bit accurate.

Again i'm sure there are experts here but with the MT and iRiver there ain't a whole lot feature wise to those units when compared to the R44. 

If you had to cut back are you cutting back a bit accurate chip or are you cutting back on preamp chips? 

[timP]

when/where did iriver come up with a bit accurate , sub $300, 24BIT recorder?


just curious...

[Rick]

when/where did iriver come up with a bit accurate , sub $300, 24BIT recorder?


just curious...

I could be wrong, but I thought I read the iRiver was proven bit accurate for 16bit.

[Todd R]

For me the measuring stick is the price.  While by appearance it looks great but with both the R4 and R4 Pro still being marketed I can't imagine that they'd undercut two current products at higher price points.

My question is, is the resampleing of a digital inputs a product of bad design or cost cutting or both? I think both the iRiver 120/140 and MicroTracker have been proven bit accurate but both are on the cheaper end of recorders… the iRiver wasn’t even primarily designed as a recorder.

I'm sure there are experts here but I always understood it to be the chips used in the gear.   I assume <---- that they cut costs by using lesser priced chips.  Also I can't imagine most of their client base is as nit-picky about this issue like we are.

I doubt it has to do with lower priced chips, but it is probably just a design choice.  Just guessing.

For background, there are probably a lot of reasons why a recorder will not be bit accurate, but the main one is that the recorder will use its internal clock/crystal for clocking the digital data stream rather than deriving the clock signal from the incoming digital data stream.

Also, in case it has been overlooked, from the R44 manual:

The R-44 is able to synchronize to the clock signal of the Digital input jack

This is in the section on digital recording, so it sounds like the R44 will not resample (will be bit accurate) when doing 2ch digital recording.

The manual doesn't say the same thing for 2ch digital + 2ch mic recording, so it might be resampling the digital stream for 4ch recording (using its own internal clock).  To do 4ch recording correctly, all the channels need to be sampled off the same clock.  The choice is either to derive that clock from the incoming digital data stream, or to use the internal clock of the R44. 

I'm guessing by reading between the lines from the responses from Edirol that for 4ch recording, the R44 is using its own internal clock (and resampling the digital input).  It would be better to use the clock data from the incoming digital stream (ie, not resample), but again, the R44 needs to use the same clock for all 4 channels (and it might be using its internal clock).

Bottom line, I'm guessing the R44 will be bit accurate for 2ch digital recording, but may not be for 4ch recording.

[Gutbucket]

Well explained, sounds reasonable.  Is the clock source the kind of thing that could conceivably be changed with a firmware patch?

[Rick]

Bottom line, I'm guessing the R44 will be bit accurate for 2ch digital recording, but may not be for 4ch recording.

I could live with that.

[Roving Sign]

Well explained, sounds reasonable.  Is the clock source the kind of thing that could conceivably be changed with a firmware patch?

Patch? - selectable clock source should be a "feature"

It shouldn't be that big of a deal to allow you to select a clock source...even my 100 dollar Behringer A/D can do that...

I can choose:

Internal
External
Dig-In

This quote would lead me to think the clock will be selectable: (from a few posts back)

The R-44 is able to synchronize to the clock signal of the Digital input jack

I would make the assumption that: If they can use dig-in for clock - it would HAVE to be bit accurate...otherwise, how could you get a reliable sync?

[Roving Sign]

but who knows.

^^^ the key three words.

FWIW, I got the same response when I bought my original R4.   Lots of things could be fact or non-fact.  Just have to have one in hand to confirm things.

For me the measuring stick is the price.  While by appearance it looks great but with both the R4 and R4 Pro still being marketed I can't imagine that they'd undercut two current products at higher price points.

...but who knows

I dont see these as equivalent machines...I would bet about 1/3 the cost of the R-4/pro is in all the "Wave Editing" software/feature set.(which the R-44 doesnt have) Edirol didnt include those for free. Despite the uselessness of on-board Wave Editing to our hobby - tapers still flocked to these devices...the device was still "worth it" for the features we wanted.

Price-wise, this seems to fit perfectly in the hierarchy of Edirol R-X series recorders...

[BayTaynt3d]

I disagree, I think this product will seriously cannabilize sales to the other units for anyone not needing timecode, but what do I know?

[DSatz]

Two observations:

1. Yes, please, let's have a thread somewhere to talk about dynamic range, mike vs. line inputs, pads on mikes versus pads on preamps, and in-line pads (an alternative which wasn't mentioned here, but is often preferable to the other two). Some of the information which people claimed as gospel truth in this thread was accurate; other such claims or assumptions, stated with equal vehemence, were not.

I wouldn't want to say that everybody overgeneralizes here, but sometimes some folks do it some, I guess.

2. If it turns out that the S/P-DIF input of this unit does something to the bits rather than storing them literally as received (and that does seem to still be an "if"), before we all condemn this, why don't we find out what it's doing to the bits? If it's removing DC offset, for example, that could be doing us a favor--or not, depending on how it's implemented. I mean, I'd prefer a straight-line approach, but not everything that is done unto a bitstream is uniformly and equally bad.

--best regards