Introducing Olympus & Olympus I/O - A new perspective on modern music playback

Taiko-Olympus-big-advert.png

For those who just started reading up on Olympus, Olympus I/O, and XDMI, please note that all information in this thread has been summarized in a single PDF document that can be downloaded from the Taiko Website.

https://taikoaudio.com/taiko-2020/taiko-audio-downloads

The document is frequently updated.

Scroll down to the 'XDMI, Olympus Music Server, Olympus I/O' section and click 'XDMI, Olympus, Olympus I/O Product Introduction & FAQ' to download the latest version.

Good morning WBF!​


We are introducing the culmination of close to 4 years of research and development. As a bona fide IT/tech nerd with a passion for music, I have always been intrigued by the potential of leveraging the most modern of technologies in order to create a better music playback experience. This, amongst others, led to the creation of our popular, perhaps even revolutionary, Extreme music server 5 years ago, which we have been steadily improving and updating with new technologies throughout its life cycle. Today I feel we can safely claim it's holding its ground against the onslaught of new server releases from other companies, and we are committed to keep improving it for years to come.

We are introducing a new server model called the Olympus. Hierarchically, it positions itself above the Extreme. It does provide quite a different music experience than the Extreme, or any other server I've heard, for that matter. Conventional audiophile descriptions such as sound staging, dynamics, color palette, etc, fall short to describe this difference. It does not sound digital or analog, I would be inclined to describe it as coming closer to the intended (or unintended) performance of the recording engineer.

Committed to keeping the Extreme as current as possible, we are introducing a second product called the Olympus I/O. This is an external upgrade to the Extreme containing a significant part of the Olympus technology, allowing it to come near, though not entirely at, Olympus performance levels. The Olympus I/O can even be added to the Olympus itself to elevate its performance even further, though not as dramatic an uplift as adding it to the Extreme. Consider it the proverbial "cherry on top".
 
Last edited by a moderator:
I got the same files from Marty and I did feel the .wav was not that noticeably better but my understanding is Marty is using a different tool I converting to .wav which has made the huge sonic improvement. I know Ed visited Marty last week and Ed reports that he was stunned as to how much better Marty's .wav files sounded in comparison to Flac , so much so that there are some plans to delve further into this and make it a reality for XDMS. Right now as I understand it in Qobuz the files are converted to .wav and that is what we hear presently BUT Marty is converting using a different tool which has caught the interest of Ed so thanks to cat6man it seems there we can all look forward to this being implemented
Maybe I’m missing something . If Marty sent you his converted files wouldn’t you be hearing the files with his conversion sq embedded in the files to also be heard on your system?
 
consensus? here??????

let me summarize a bit (even though this is the olympus/wrong thread, right?).

ed was kind enough to drop by on monday to meet, talk deep audio techno geek, and listen to my system.

this is the music we played

there are 3 directories, flac (the original files), wav-db (converted to wav by dbpoweramp) and wav-ff (converted to wav by ffmpeg). ed and i only listened to flac and wav-db (more on this later). in every case, ed and audio-bud carl were able to correctly identify the wav vs. flac file in the first 5-10 seconds of each track (hopefully confirming that i am not crazy).

setup: local files on extreme with jan11 backend software, latest android client app, router, switch and power distributor fed by battery power. usb out of extreme to sotm usb-aes/ebu converter (with superclock option, also battery powered), aes/ebu out to totaldac reclocker, aes/ebu output to totaldac triunity dac, balanced out to passlabs preamp, ayon triton monoblocks in triode mode, Nola metrogrande speakers.

[warning: nerd talk follows]

now, the next day ed and i were chatting and he mentioned that christian had been listening to some downloads and had noticed a difference between files, which got us wondering. the extreme uses ffmpeg to decode flac to wav before playback while i was using files pre-converted to WAV. perhaps the difference in sound, so obvious here, was the extra processing (more processing ==> more noise) from the file conversion.

a good way to test this hypothesis was to use ffmpeg offline to convert flac to wav.
on my linux pc (no windows or apple here), this was simple:

#!/bin/bash

# This script converts all .flac files in a directory to .wav using ffmpeg
# If ffmpeg is not installed run:
# sudo apt update
# sudo apt install ffmpeg

# Create a new folder for converted files
mkdir wav
# For each file in .flac files directory
for f in *.flac
do
# Convert to .wav keeping the same file name
ffmpeg -i $f ./wav/$(basename -- "$f" .flac).wav
done
@gboisvert

so, after creating the files in subdirectory wav-ff, i compared the wav-db with the wav-ff files.
the result was completely the opposite of what i'd expected, as the wav-db files sounded much
better than the wav-ff files. yes, two different WAV files sounded different, with the wav-ff file being much closer to the
original flac file. therefore, it seems to me that the structure of the wav files created by the converter
matters (a lot) and the degradation of flac may be due to the flac to wav conversion and/or wav file structure, even when that conversion is done offline! exactly the opposite of what i had hypothesized, which is a good reason to test ones assumptions even when you're sure (as i was) of the outcome.

a little web research (see wikipedia for WAV RIFF discussion) shows that the definition of wav file structures is not
the most well-defined standard out there. running mediainfo in detailed mode shows the RIFF structure of the wav-db
and wav-ff files are not identical. exactly what the cause may be consitutes a level of detail i'd love to know but don't have the
patience or skill to pursue further. perhaps this is due to the way the WAV file is packaged?

one of the links in the wikipedia article led me to this, which i excerpt here:

[excerpt starts]
Another way of storing waveform data
So, you're thinking "This WAVE format isn't that bad. It seems to make sense and there aren't all that many inconsistencies, duplications, and inefficiencies". You fool! We're just getting started with our first excursion into unnecessary inconsistencies, duplications, and inefficiency.

Sure, countless brain-damaged programmers have inflicted literally dozens of compressed data formats upon the Data chunk, but apparently someone felt that even this wasn't enough to make your life difficult in trying to support WAVE files. No, some half-wit decided that it would be a good idea to screw around with storing waveform data in something other than one Data chunk. NOOOOOOOOOOOOOO!!!!!!

For some god-forsaken reason, someone came up with the idea of using an imbedded IFF List inside of the WAVE file. NOOOOOOOOOOOOOOOOO!!!!!!!! And this "Wave List" would contain multiple 'data' and 'slnt' chunks. NOOOOOOOOOOOOOOOO!!!! The Type ID for this List is 'wavl'.

I strongly suggest that you refuse to support any WAVE file that exhibits this Wave List nonsense. There's no need for it, and hopefully, the misguided programmer who conjured it up will be embarrassed into hanging his head in shame when nobody agrees to support his foolishness. Just say "NOOOOOOOOOOOOOO!!!!"
[excerpt ends]

i don't know if this specific issue is at play here (i certainly have no evidence that it does), but i so enjoyed reading this guy's passion on the subject.

[end techno geek]

so what have i concluded:
1. in my system, WAV files created by dbpoweramp vastly outperform flac files and WAV files created by ffmpeg.
2. since the extreme is using ffmpeg to decode flac (and therefore all current streaming options), there is great potential to improve the sound of streaming sources, at least in my system. as i told ed, "maybe then i'll be able to tolerate streaming." :cool:
3. why doesn't everyone hear what ed, carl and i heard? how could this be system dependent? i trust the ears of many of the knowledgable folks here, but i am at a loss to understand why/how this large difference in SQ is perceived differently. but good things should come out of a deeper understanding.
4. does this change with other than 16/44 red book files? i don't know but will test that (now that i've thought of it).
5. perhaps your system have better/cleaner power or cables or ......?

have a good weekend everyone.

marty (aka cat6man)
Might be nerd talk but got to love it!! Impressive!
 
Thanks for the explanation Marty.....not saying I completely understand it but talking to Ed about it this morning he was so taken by the sonic difference in .wav vs .flac he has already made some inquiries with the person who has designed what you are using. I gather he is in the UK. There are 2 versions I think and Ed was talking about the pro version. The good news for me is that as always you are so much deeper on the curve than the rest of us and with Ed's verification of your findings there is some thought that this can be implemented into XDMS. That for me is wonderful and kudos to you Marty for being persistent in your findings that prompted Ed's visit and confirmation of your findings
 
  • Like
Reactions: cmarin and DW101
Maybe I’m missing something . If Marty sent you his converted files wouldn’t you be hearing the files with his conversion sq embedded in the files to also be heard on your system?
confuses me as well . I did hear a difference but not to the extent that Marty describes so yes I am scratching my head in wonder
 
confuses me as well . I did hear a difference but not to the extent that Marty describes so yes I am scratching my head in wonder
Remember a few days ago Emile commented that to his ears now Tidal for reasons he doesn't fully understand sounds better now than Qobuz. All of this is beyond my pay grade but when Ed gets excited about something you can bet it is worth further evaluation. I do remember a few months ago when the Qobuz change was made and Flac was converted to wav and we all commented about the sonic uptick in Qobuz
 
Thanks for the explanation Marty.....not saying I completely understand it but talking to Ed about it this morning he was so taken by the sonic difference in .wav vs .flac he has already made some inquiries with the person who has designed what you are using. I gather he is in the UK. There are 2 versions I think and Ed was talking about the pro version. The good news for me is that as always you are so much deeper on the curve than the rest of us and with Ed's verification of your findings there is some thought that this can be implemented into XDMS. That for me is wondeful and kudos to you Marty for being persistent in your findings that prompted Ed's visit and confirmation of your findings
So, Ed heard a major sq enhancement when listening to Marty’s system in person. I’m wondering what Ed hears at home, or Taiko HQ, when duplicating Marty’s conversion process?
 
I am definitely confused (but open-minded) by the notion that different audio conversion software results in wav files that sound different. It completely contradicts my notion of what these encoding software packages do. Why aren't they all behaving like winzip? Every time I unzip a file I get what I started with. It would be bad if I ended up with a different spreadsheet each time.

What don't I understand about all this?
 
  • Like
Reactions: StreamFidelity
consensus? here??????

let me summarize a bit (even though this is the olympus/wrong thread, right?).

ed was kind enough to drop by on monday to meet, talk deep audio techno geek, and listen to my system.

this is the music we played

there are 3 directories, flac (the original files), wav-db (converted to wav by dbpoweramp) and wav-ff (converted to wav by ffmpeg). ed and i only listened to flac and wav-db (more on this later). in every case, ed and audio-bud carl were able to correctly identify the wav vs. flac file in the first 5-10 seconds of each track (hopefully confirming that i am not crazy).

setup: local files on extreme with jan11 backend software, latest android client app, router, switch and power distributor fed by battery power. usb out of extreme to sotm usb-aes/ebu converter (with superclock option, also battery powered), aes/ebu out to totaldac reclocker, aes/ebu output to totaldac triunity dac, balanced out to passlabs preamp, ayon triton monoblocks in triode mode, Nola metrogrande speakers.

[warning: nerd talk follows]

now, the next day ed and i were chatting and he mentioned that christian had been listening to some downloads and had noticed a difference between files, which got us wondering. the extreme uses ffmpeg to decode flac to wav before playback while i was using files pre-converted to WAV. perhaps the difference in sound, so obvious here, was the extra processing (more processing ==> more noise) from the file conversion.

a good way to test this hypothesis was to use ffmpeg offline to convert flac to wav.
on my linux pc (no windows or apple here), this was simple:

#!/bin/bash

# This script converts all .flac files in a directory to .wav using ffmpeg
# If ffmpeg is not installed run:
# sudo apt update
# sudo apt install ffmpeg

# Create a new folder for converted files
mkdir wav
# For each file in .flac files directory
for f in *.flac
do
# Convert to .wav keeping the same file name
ffmpeg -i $f ./wav/$(basename -- "$f" .flac).wav
done
@gboisvert

so, after creating the files in subdirectory wav-ff, i compared the wav-db with the wav-ff files.
the result was completely the opposite of what i'd expected, as the wav-db files sounded much
better than the wav-ff files. yes, two different WAV files sounded different, with the wav-ff file being much closer to the
original flac file. therefore, it seems to me that the structure of the wav files created by the converter
matters (a lot) and the degradation of flac may be due to the flac to wav conversion and/or wav file structure, even when that conversion is done offline! exactly the opposite of what i had hypothesized, which is a good reason to test ones assumptions even when you're sure (as i was) of the outcome.

a little web research (see wikipedia for WAV RIFF discussion) shows that the definition of wav file structures is not
the most well-defined standard out there. running mediainfo in detailed mode shows the RIFF structure of the wav-db
and wav-ff files are not identical. exactly what the cause may be consitutes a level of detail i'd love to know but don't have the
patience or skill to pursue further. perhaps this is due to the way the WAV file is packaged?

one of the links in the wikipedia article led me to this, which i excerpt here:

[excerpt starts]
Another way of storing waveform data
So, you're thinking "This WAVE format isn't that bad. It seems to make sense and there aren't all that many inconsistencies, duplications, and inefficiencies". You fool! We're just getting started with our first excursion into unnecessary inconsistencies, duplications, and inefficiency.

Sure, countless brain-damaged programmers have inflicted literally dozens of compressed data formats upon the Data chunk, but apparently someone felt that even this wasn't enough to make your life difficult in trying to support WAVE files. No, some half-wit decided that it would be a good idea to screw around with storing waveform data in something other than one Data chunk. NOOOOOOOOOOOOOO!!!!!!

For some god-forsaken reason, someone came up with the idea of using an imbedded IFF List inside of the WAVE file. NOOOOOOOOOOOOOOOOO!!!!!!!! And this "Wave List" would contain multiple 'data' and 'slnt' chunks. NOOOOOOOOOOOOOOOO!!!! The Type ID for this List is 'wavl'.

I strongly suggest that you refuse to support any WAVE file that exhibits this Wave List nonsense. There's no need for it, and hopefully, the misguided programmer who conjured it up will be embarrassed into hanging his head in shame when nobody agrees to support his foolishness. Just say "NOOOOOOOOOOOOOO!!!!"
[excerpt ends]

i don't know if this specific issue is at play here (i certainly have no evidence that it does), but i so enjoyed reading this guy's passion on the subject.

[end techno geek]

so what have i concluded:
1. in my system, WAV files created by dbpoweramp vastly outperform flac files and WAV files created by ffmpeg.
2. since the extreme is using ffmpeg to decode flac (and therefore all current streaming options), there is great potential to improve the sound of streaming sources, at least in my system. as i told ed, "maybe then i'll be able to tolerate streaming." :cool:
3. why doesn't everyone hear what ed, carl and i heard? how could this be system dependent? i trust the ears of many of the knowledgable folks here, but i am at a loss to understand why/how this large difference in SQ is perceived differently. but good things should come out of a deeper understanding.
4. does this change with other than 16/44 red book files? i don't know but will test that (now that i've thought of it).
5. perhaps your system have better/cleaner power or cables or ......?

have a good weekend everyone.

marty (aka cat6man)
Very informative, and thank you for the comparison files to download. I'm very curious to try the same comparison in my own system, but I'm feeling dense: how best to run these via the Extreme to test SQ differences? How do you store them with differentiation and play them so you know what it is your evaluating?
 
I am definitely confused (but open-minded) by the notion that different audio conversion software results in wav files that sound different. It completely contradicts my notion of what these encoding software packages do. Why aren't they all behaving like winzip? Every time I unzip a file I get what I started with. It would be bad if I ended up with a different spreadsheet each time.

What don't I understand about all this?

dave

i think you do get the exact bits back, but i can hypothesize that if the bits are packed differently they might be processed and sent on in a different format (possibly)............just winging it here but what if data is split into packets differently? one thing i learned is that the WAV format puts the LSB (least significant bits) first, then padding, then the rest of the MSB (most significant bits). this means the sample value has to be reconstructed at the bit level. again, i'm guessing here but i suspect that may be one of the things that hqplayer does to drastically lessen the processing load on their proprietary NAA endpoint (though i've never seen a published spec for the NAA input structure, it would make sense to strip out the padding and put the sample bits back in proper order, then send the sample to the NAA to be passed on)

Very informative, and thank you for the comparison files to download. I'm very curious to try the same comparison in my own system, but I'm feeling dense: how best to run these via the Extreme to test SQ differences? How do you store them with differentiation and play them so you know what it is your evaluating?

the folder 'temp' has subfolders. if you put the 'temp' structure in your music directory and scan them in, just add the entire 'temp' folder to the play queue. while the file names are the same, the queue will show which sub-folder a given file came from.
 
Last edited:
to avoid clogging up this thread, anyone who wants to contribute should:
1. download tracks in 'temp' folder, put on your extreme local drive, scan, then queue the 'temp' folder into the xdms player.
2. please report your results (flac, wav-db and wav-ff) to me via DM and i'll collate the responses and report back here.
3. with your observations, please indicate the DAC you are using and all selectable DAC settings in the client
including sound profile, asio format and pcm settings, player setting (xdms/roon), ram disk size (if not default).

the tracks were all selected for their ability to quickly demonstrate differences in SQ. i most highly prize soundstage,
instrumental separation, low level detail presented without harshness.

let's see if any commonalities show up (e.g. buffer size interacting with wav file structure, packet size processing in usb driver, who knows..........)

the tracks i've looked at so cover jazz, folk and rock. i need to create a couple of classical (chamber & symphonic) tracks next.
then i'll see if 24/96 or 24/192 make a difference. by the way, no native DSD here, just DoP mode and the maximum bit rate accepted by the TotalDAC is 24/192.
 
Maybe I’m missing something . If Marty sent you his converted files wouldn’t you be hearing the files with his conversion sq embedded in the files to also be heard on your system?

good question.

personally, i don't think the SQ is embedded in the files but something is 'different' in the WAV file structures. i think there are interactions with other processing functions which could differ from system to system (e.g. usb buffer size).

bits really are bits..............how they are transported and processed is what matters. as we have learned here from emile et team, everything matters. the bits are (unless something is broken) exactly the same in flac, wav-db and wav-ff. how they are transported and processed has the potential for all sorts of interactions.

another, off the top of my head, example that could be dac related. assuming red book, does the dac receive 16 bit words or does it receive 24 bit words with 8 zeros appended. does the dac treat them the same or differently? lots of potential variables amongst systems. again, i'm not suggesting that these things are implicated but an almost infinite number of implementations are possible.
is my totaldac more sensitive to whatever is going on?
 
Last edited:
good question.

personally, i don't think the SQ is embedded in the files but something is 'different' in the WAV file structures. i think there are interactions with other processing functions which could differ from system to system (e.g. usb buffer size).

bits really are bits..............how they are transported and processed is what matters. as we have learned here from emile et team, everything matters. the bits are (unless something is broken) exactly the same in flac, wav-db and wav-ff. how they are transported and processed has the potential for all sorts of interactions.

another, off the top of my head, example that could be dac related. assuming red book, does the dac receive 16 bit words or does it receive 24 bit words with 8 zeros appended. does the dac treat them the same or differently? lots of potential variables amongst systems. again, i'm not suggesting that these things are implicated but an almost infinite number of implementations are possible.
is my totaldac more sensitive to whatever is going on?
Assuming good quality processing to get those bits, bits are really just bits which is true, as is your point regarding how they are transported, cached, and processed. How they are stored (organized) when written, how much effort and complexity it takes to extract the various parts (blocks or clusters, etc depending on the storage medium, filesystem in question, etc) from storage and get them ready to be transported (whether in the box or over the channel/bus or wire) and other parts of the equation all also matters.
 
I just revisited the original 3 files Marty sent me in December
Very close
The Duke Ellington .wav file gets the nod for me
The other 2 a toss-up, especially Baby Blue
 
Last edited:
so what have i concluded:
1. in my system, WAV files created by dbpoweramp vastly outperform flac files and WAV files created by ffmpeg.
2. since the extreme is using ffmpeg to decode flac (and therefore all current streaming options), there is great potential to improve the sound of streaming sources, at least in my system. as i told ed, "maybe then i'll be able to tolerate streaming." :cool:
3. why doesn't everyone hear what ed, carl and i heard? how could this be system dependent? i trust the ears of many of the knowledgable folks here, but i am at a loss to understand why/how this large difference in SQ is perceived differently. but good things should come out of a deeper understanding.
4. does this change with other than 16/44 red book files? i don't know but will test that (now that i've thought of it).
5. perhaps your system have better/cleaner power or cables or ......?

That is very interesting. When you were posting your "wav vs. flac" findings on Discord, I would always wonder: he does know that XDMS does the flac decompression and conversion to wav before playback, doesn't he? If so, why should it possibly be different?

Now I understand where you're coming from. Who'd'a thunk that WAV's created by dbPoweramp would sound different than ffmpeg. I hope the Taiko boys get to the bottom of this, and perhaps there is some additional SQ we can get out of this.

Thanks for these experiments!
 
That is very interesting. When you were posting your "wav vs. flac" findings on Discord, I would always wonder: he does know that XDMS does the flac decompression and conversion to wav before playback, doesn't he? If so, why should it possibly be different?

Now I understand where you're coming from. Who'd'a thunk that WAV's created by dbPoweramp would sound different than ffmpeg. I hope the Taiko boys get to the bottom of this, and perhaps there is some additional SQ we can get out of this.

Thanks for these experiments!

Does that mean we just need to re-encode all our flacs using ffmpeg?
 
I have little doubt that the SQ of XDMS NSM on the Olympus will eclipse Roon
That's hardly a surprising statement. The SQ of XDMS is superior to Roon now. As I said, I genuinely I appreciate the development efforts and goal of XDMS, but its just not usable for the way I listen to music the majority of the time. Let's just stick to "YMMV" and remain optimistic that XDMS's full merits will be available on the Olympus with native XDMI in due time.
 
In my system the sound quality of XDMS is clearly better than Roon.

Hopefully I will get my Olympus XDMI in May, so after I ship back my Extreme, no more XDMS for me for a while, only Roon.

Since many XDMS users/testers will be converting to Olympus, Taiko will probably lose most of the XDMS alpha testers. We will be back months later when testing of the Olympus XDMS becomes available.
 
Last edited:

About us

  • What’s Best Forum is THE forum for high end audio, product reviews, advice and sharing experiences on the best of everything else. This is THE place where audiophiles and audio companies discuss vintage, contemporary and new audio products, music servers, music streamers, computer audio, digital-to-analog converters, turntables, phono stages, cartridges, reel-to-reel tape machines, speakers, headphones and tube and solid-state amplification. Founded in 2010 What’s Best Forum invites intelligent and courteous people of all interests and backgrounds to describe and discuss the best of everything. From beginners to life-long hobbyists to industry professionals, we enjoy learning about new things and meeting new people, and participating in spirited debates.

Quick Navigation

User Menu