Any chance of having the Receiver support uncompressed audio formats? Unlike in the car, at home I have as much disk space as I want, and would prefer to have *real* CD quality instead of MP3.

Also, any plans on support for streaming? It's a pity I can't use the Receiver to listen to web sites...

Thanks,

Julf

Streaming has been discussed as a possible future feature.

However, uncompressed audio is unlikely as this would saturate the network bandwidth and overload the cache of the receiver.

Your statement seems to imply that MP3 can't ever sound as good as a CD. If you take the time to create your MP3 files carefully, they can. Check the FAQ section at riocar.org for some generic information on creating good MP3 files.

__________
Tony Fabris

Hmm.. Saturate network bandwidth? Normal uncompressed CD audio is less than 1 Mbps. No problem even on good old slow (10M) ethernet. In fact, works great over an overstretched WLAN that drops down to 2M.

Overload cache? How short on memory is the receiver?

And yes, I do dare to imply that MP3's don't sound as good as CD's. Not even when ripped and encoded very carefully, and with a very good encoder. MP3 is very, very good considering how much it compresses, but it still discards a *lot* of information. And yes, I do hear a difference. Very easily. Not in a car, but definitely at home, with good speakers. And the receiver's D/A is capable of pretty good sound!

Julf

Well, the Receiver was designed for multiple units to talk on the same set of lines at the same time.

Remember that even though ethernet is theoretically 10mbps, it kinda depends on how the bandwidth is getting used that will determine your actual throughput. I would guess that HPNA is even less capable than ethernet in handling saturating traffic.

Unlike most network traffic, which is really bursty, the Receiver needs to have the data streamed continuously. Sure, one or maybe two receivers on the same network wouldn't be much of a problem, but imagine a home with five receivers, all streaming uncompressed CDs at the same time.

Plus... where are you going to store all this full-bandwidth stuff?

And I'll take you up on the MP3 vs. WAV challenge sometime. There are certain kinds of audio where I can tell the difference at low bit rates (128), but when you start pushing up the bit rate with a good encoder, I would not be able to tell the difference on a double-blind test.

__________
Tony Fabris

Have no experience with HPNA, but I've run ethernets with over 50% saturation. Not to be recommended. That's why I use switches (not hubs), and at least 100M between the switches. No problem supporting dozens of *video* streams.

Five receivers, all receiving uncompressed CD, is not very different from five PC's showing MPEG2 2Mbps video. And I've sucessfully done that with 15 PC's.

Anyway, can't imagine when I would like to have 5 *different* streams going on in my house - I can imagine having one stream into the main hi-fi system for *real* listening, and another "background listening" stream into the rest of the house, but when I go from one room to another, I prefer for the *same* music to continue. But the receiver probably doesn't handle multicast either.

Storing it is easy - with 160G IDE disks, and good multiple-IDE RAID controllers, it's not too expensive and hard to put together your own 1Terabyte server.

More than happy to take you up on the MP3 vs. WAV challenge. I can definitely hear the diference on the Linn Isobariks, but usually I can hear it on the movie room Tannoys as well, and even after a couple of glasses of wine. At 256K.
Let's do a listening test next time you're in Amsterdam

Julf

But the receiver probably doesn't handle multicast either.

This was requested as a feature once. No word on whether it's actually planned for a future release or not.

Let's do a listening test next time you're in Amsterdam.

Double-blind test protocol, I pick the encoder.

Only catch is that the playback device must play both raw WAV files and MP3 files. If you compare a CD player to an MP3 player, you're comparing apples to oranges in terms of playback circuitry...

__________
Tony Fabris

No prob! PC driving high-end D/A OK? Or should we just get together, twist some arms, and get someone to implement WAV playback on the Receiver just so that we can compare?

Julf

I think a better approach would be:

• rip the test track to a WAV
  
• encode the WAV file to MP3 with the selected encoder
  
• decode the MP3 file to a WAV file using WinAmp (or something similar)
  
• right both WAV files to an Audio CD
  

Now test both tracks on a decent CD player.

True. But that doesn't allow for side-by-side blind comparision.

Actually, that is exactly the correct way to test encoders. Some of the best double-blind tests have been done this way. I actually saw one published in an online article. Unfortunately, I don't have the link to it any more. Still, it was a perfect test protocol.

The protocol for the test was complex, and it involved multiple CDs with the samples in a random order, like this:

- Original WAV
- Encoder A
- Encoder B
- Encoder C
- Original WAV

The first one (the "reference" track) was always the first in a given group. The last four were always randomized on the burned CD. So the person listening to the CD did not know which of the remaining four was simply a repeat of the reference track.

Several CDs with different randomizations were made and assigned serial numbers. The order of the tracks were kept in a spreadsheet, but the contents of the spreadsheet were not made public until the end of the test. The listeners only were told to compare each of the four successive tracks to the original reference track and then rate them.

The repeat of the reference track among the comparison tracks was the "control". It should have always gotten a perfect score. Sometimes, it didn't. One's ears can play tricks.

__________
Tony Fabris

My receiver's hooked to a 10/100 Mbit switch, which are pretty cheap now, and the server's on 100 Mbit, so I doubt I'd overload my network, even if I played all 4 at once.

I tried comparing the receiver to a CD-Player of the same track. They synced pretty easily so it was easy to switch them back & forth. At 128K, there was a noticable difference. I wouldn't rule out the encoder (older MusicMatch), but it bothered me.

I just retried the test, and couldn't hear an obvious difference, but (A) I used different music and (B) I used worse speakers.

I'd love to be able to play the raw .wav's just to do a better test, even if that's not normally how I'd store them.

- Shawn

I tried comparing the receiver to a CD-Player of the same track. They synced pretty easily so it was easy to switch them back & forth. At 128K, there was a noticable difference. I wouldn't rule out the encoder (older MusicMatch), but it bothered me.

At 128k, depending on the music, you might indeed hear a difference between the MP3 and the original. 128k is the bare-minimum level of encoding where Joe Six-pack won't know the difference. I know that I can clearly hear compression artifacts on some 128k files, and it's not subtle if you know what to listen for.

However, there are some other factors besides the MP3 encoding that you need to realize before doing an A/B test like the one you described:

1) The CD player and the MP3s are going through different audio output circuitry, and as such, will have different equalization curves. So to begin with, you're not comparing apples to apples.

2) I don't know whether or not the MP3 was ripped correctly (i.e., no errors in the rip). That might cause it to sound different/bad, but wouldn't necessarily be the fault of the encoder. Remember that ripping and encoding are two different steps.

Both of those can be taken care of by the one-burn audio testing schema described earlier in this thread.

__________
Tony Fabris

www.r3mix.net

Lots 'o MP3 goodness!

[snip] double-blind [snip] randomized [snip]

Tony, you've just put a hole in my long-cherished theory that nobody in the audiophile business has ever done a proper double-blind test. (Although your description doesn't make it clear whether even the experimenters didn't know which order the tracks came in until after the experiment was complete, which is the essential condition for double-blindness as opposed to single-blindness).

Peter

Yeah, I wish I had a link to the original test, still. The testing protocol was rather clever.

And yes, it was fully and truly double-blind. They randomized the order of the tracks burned onto the CD (within each group), then coded the actual track order onto a spreadsheet. They made a few sets of CDs, then assigned each one a random serial number, and randomized which end-listener got which CD. Then the end-listeners got to listen to each CD on their own favorite equipment and report their findings back along with the CD serial number.

Then a simple spreadsheet program correlated the results based on serial number.

I wouldn't be so sure about that.. depending on the quality of the switch's internals, it is very likely that when your server is feeding a 10mbs device, it is running at 10mbs, meaning that five or six full-CD-rate streams would likely clog the pipe completely.

cheers