Modi Multibit: Multibit for the masses.

Yeah, you guys clearly know lots more than me about this stuff. This "lost packets" stuff just fights my common-type of thinking about this subject - I never get typos on my Word-docs through USB or anything else. Also lacking/corrupted info in an audio-file should, by my common sense, be easily heard by anyone. Added noise I can comprehend, though. But I need to get an idea how much it actually affects my hearing db-level wise.

This isn't really about the ModiBit, hmm. Thanks for answering.

 

You don't get "lost packets" (or bits, or whatever) on your Word documents, or anything else storage-related as the USB protocols use there DO have error detection, correction and re-transmission. Audio doesn't. It's stupid ... would have been VERY easy to accommodate (at the cost of some minimal latency), but it's just not there.

Your "common type of thinking" is assuming that all USB data transfer occurs the same way - but it doesn't. Understanding the ISO 7-layer model would help you separate what was specific to the PHY level of the connection and what was layered on top of that.

 

I think my post was a little misguided.

I think I am so used to the D/S signature, that R2R is proving to have a learning curve, almost like the mind has to relearn how to listen to music, because now it sounds a lot more "correct" in terns of presentation. I'd heard people talk about it but didn't realize how true it was until now. Years and years of listening to a sort of more 2D presentation can prove difficult to let go of. At least for me. At first I was astounded at the more 3D like holographic stage, then perhaps I went through a sudden withdrawl and started looking for "flaws" as a defense mechanism.

Its been an interesting ride to say the least. Switching from SS to tubes at the same time certainly didn't help matters.

 

Well I thought I'd share my experience with the new Schiit Modi 2 MB as my first post since reading all the impressions here compelled me to try it. I also recently acquired an Audio-GD DAC-19 (10th Ann.) so I am looking forward to comparing the two over time.

In the meantime, I'll keep this short and sweet. The new Modi 2 MB was burned in for 48 hours before I dropped it into my speaker rig including the microRendu and olive Naim gear feeding PSB speakers. Result: Atomic quality PRAT (emotional tractor-beam) and tons of micro-detail up and down the spectrum with all instruments. Congested recordings unfold, and vocals are actually intelligible. Snare drums snap sharp like at football games, and bass sounds great, goes low and is tight.

My only complaint/adjustment is the brightness. My system before was needing some upper treble frequency speed and/or transparency; it seemed a little rolled off. The Schiit delivered, but maybe too much? I get the sense things are a little V shaped in the frequency curve. I hope the mids come into bloom after some more hours of cooking. And I do mean cooking--this thing is very hot to the touch in its daily use (I leave it on all the time).

Some test material:
* Yes / 90125, Going for the One, Union
* Rush / Signals, Power Windows
* Nojima Plays Liszt, Ravel
* Hammer Klavier Trio / Rocket in the Pocket
* The Bad Plus / Give

Certainly FUN to listen to--foot tapping, head bobbin' (bangin') fun. For the price, what a deal! Thank you, Schiit.

 

@kukur9 I actually find the Modi Multibit quite midcentric. I consider its mids as one of its greatest attributes; larger than life with a degree of realism that's almost palpable.

Give it some burn in time and you'll see too.

 

Looking forward for your comparrison with DAC-19.

 

Right, thanks. I didn't get the impression from others that this DAC has a V shaped sound. More burning in to follow...

 

I should have said there is no useful error detection, nor any re-sending of data.

Asynchronous USB Audio 2.0 uses the Isochronous transfer mode. While this does still retain the CRC for the data, there's no mechanism to resend that data, nor any time in which to do so. The receiver can make a determination as to what it wants to do with the bad data, but can't get it resent in this mode. So you're still buggered.

Since the CRC is just a simple checksum and not actual ECC data, all you know is that the data received isn't what was sent. You don't have enough information to do any kind of informed reconstruction - so you're either going to get a drop-out or the receiver has to guess/make-up the data it plays. Different implementations do different things there; Chord DACS, for example, mute when there is a data fault - so you'll get a short drop-out.

 

S/PDIF (both on optical and electrical interfaces) and AES3 (on which S/PDIF is based) have no ECC capability either. They're also one-way protocols, with no control flow etc. The source just sends data at the appropriate rate, in the appropriate format - if there's no one there to receive it, the source doesn't care.

 

Actually getting bad data at audio data-rates is pretty un-common unless you're using a really screwed up cable, you're wrapping it around an AC-power line, or have far too long a cable run or, of course, there's something wrong with the sender or receiver. With optical, we're dealing with on-off pulses of light (from a quantum source, not a thermal one) and with COAX or USB it's 0-5 volt signals. It takes a fairly gross error to get those out of whack.

Timing is generally the bigger issue for S/PDIF (unless you buffer and re-clock, which means you get latency in the receivers response to any changes from the source, e.g. hitting play or stop, etc.).

Noise on the lines (power or data) is generally a bigger problem for USB - though there are potential timing issues if you don't run Async, high-speed, and keep your implementation nice and tight.

Properly implemented COAX S/PDIF and AES will be galvanically isolated (transformer), so you'd need a massively noisy source, or a not-to-spec S/PDIF interface for this to be much a problem here. Of course, there is no guarantee that an S/PDIF interface HAS been properly implemented!

 

No argument from me!

I do not use USB for audio unless forced too (which pretty much means travelling with a laptop and not having time/space for a dedicated audio player). I use AES/EBU XLR when possible, then TOSLINK (with proper cable, which isn't expensive), and then COAX. And even then, ideally not fed from a general purpose computer, preferring a purpose-built interface unit (RedNet, Aries, etc.).

And I'm firmly in the camp that thinks alll the USB-defuckifiers can, at best, get you back to where you'd be if you just didn't use USB in the chain in the first place. Why spend money and add complexity if you can avoid the issue entirely in the first place?