New adventures in Hi Fi, my exploration of computer audio

[Le Concombre Masqué]

My system (so was my relative mania) was laid to rest for several years.

 

 

Since my (once was reference, very expensive) cd player refused to wake up, I turned to computer based audio (using my MBP Retina 15”).

 

 

I used to hear differences based on the cleaning fluid applied on my vinyls (cleaner grooves are wider grooves; i.e. the bass extension provided by Smart - Premier Pre-Cleaner, even on brand new records, is amazing); I could not resist exploring sonic impacts in the computer audio realm.

 

Here are my findings:

 

 

Respect endianness (relates to file/processor interaction ; further readings might be : The FLAC Audio Format | Start at Zero and aiff). Apple discretely turned AIFF little endian: it matters. FLAC is big endian while Intel processors are little endian. WAV is the uncluttered little endian file format: convert your files to wav just before playing (store flacs for size & tagging). It takes seconds with XLD (Mac) and it’s free (though we should all donate). Yes FLAC offers lossless compression and all your bits are there; but it doesn’t sound as good as AIFF-C and WAV is even better. Because of endianness.

To exit any process that can have a hold on a file, including the Finder, seems best practice.

 

 

Minimize CPU load

Yes, you already know that and quit all unnecessary applications etc, but… Using Audirvana +, I heard horrors when streaming audio files from my Time Capsule, because of longer processing times keeping the processor highly active while the track had started playing. Google “RFI” and you will know why it sounds awful. Now I first import on my ssd and wait for the cpu load to come back to zero or so before I launch a track. I wish Damien Plisson would implement an option allowing us to preprocess and load a whole album in RAM, ahead. I think that the sequential processing from track to track is a major design flaw that defeats part of the “Full memory play” promise; in the “Tracks loading, decoding, format conversion complete before playback to ensure best Sound Quality” claim, there should not be a “s” to (more than a few)tracks. Check your Activity Monitor. For the same reason of almost continuous cpu load and thus, RFI, playing isos was also unbearable to my ears. Take the time to extract dff from your isos with sacd extract.

 

 

EQ & deess

 

 

I love my music scary, to involve my whole skin in the listening experience. I can comfortably enjoy the 2 drums + 2 basses interplays in Daft Punk/Moroder’s Georgio and be worried for my things and walls by the deep electronic notes at the very end: I don’t listen through headphones. And thus have room interactions.

 

 

I enjoyed Amarra very much, over Audirvana, until I could go further with a Audirvana 1.54/iZotope Alloy 2 combo.

 

 

My eq is based on Amarra’s setting for classical with an emphasis of the deep in the 800 Hz region, maybe because of my room.

 

 

Amarra’s :

 

 

 

 

 

My EQ :

 

 

 

 

 

 

 

My deesser setting :

 

 

 

 

 

 

 

the whole idea is to apply a dynamic eq that never interferes with acoustic music (never saw my deesser triggered by any kind of classical music).

 

 

Do I interfere with the original mix, the artist (engineer) intention etc ? oh yeah ! So do you anyway by the mere simple act of playing back music on your system with its idiosyncratic characteristics. I feel perfectly comfortable, subtly and surgically, smoothing vocals when they are shrieking on a reference grade system because of a mix/mastering for cheap record players years ago or smartphones nowadays.

 

 

Give it a try: you will crank the volume up and get a much more concert like, realistic, playback.

 

 

Think twice about DSD

 

 

Especially if you’re a Mac user. I purchased the TEAC UD 501 partly because of its DSD capabilities. However, I now convert to PCM through Audirvana (cleaner to my ears than Audiogate, though with a loss of bass weight).

 

 

Mainly, it allows me to benefit from iZotope Alloy 2. With a slightly different eq to compensate for the loss of bass weight :

 

 

 

 

 

Furthermore, though Audirvana can feed the TEAC via DoP (and bits are preserved, OK) it does not automatically detect the device as DSD native though it is. I wonder (read : I doubt) if the global process is optimum.

 

 

Anyway, I never liked what I heard feeding the TEAC with DSD from the Mac (DoP mode); I enjoy very much my converted eqed dff files…

 

 

Choose the right filter

 

 

There might be a rational for playing back pcm through the TEAC with a sharp filter for redbook, a slow filter for 96 K, and no filter above…

 

 

Well, now we get bored, don’t we ?

 

 

I turned the upconverter on and the PCM filter off and am happy… ("Minimal Phase filter", see : Archimago's Musings: MEASUREMENTS: Digital Filters and Impulse Response... (TEAC UD-501)).

 

 

Cheers ,

 

 

Le Concombre Masqué

 

 

P.S. : I have long been an analogue enthusiast and record collector.

I have been blown away by what Paul Stubblebine did on Waltz for Debby for HDtracks (I own a test pressing of the Acoustic sounds 45 rpm ; always found it much inferior to its SatVV sibling though) or by what Kevin Reeves did on the Velvets for HDtracks (I own an unbrushed Eric Emerson cover very first pressing).

[InfernoSTi]

Very nice post, Sir!

 

I think I have agreed with you on many of the issues, if perhaps due to intuition more than explanation. I attacked room interaction with room treatments, not DSP, but a similar problem and two ways to get to the top of the mountain. I do have to disagree on DSD but I'm using Windows CAPS, not Mac, so that is a qualifier that may hold up...and certainly I respect your findings on your equipment to your ears!

 

Best,

John

[souptin]

Welcome to CA, Mr Masked Cucumber. And may I say how nice it is to see another grocery product on the board.

[wkhanna]

What a wonderful introduction! Welcome!

 

 

However, I seem to have found an alternate translation.

 

 

 

[Paul R]

Welcome to CA. Looks to me like you have jumped in with both feet and are fast learning what you like! It's a fun adventure!

 

Have to ask though - The Cucumber Mask? Or the Masked Cucumber?

 

-Paul

[mayhem13]

Welcome to CA. Looks to me like you have jumped in with both feet and are fast learning what you like! It's a fun adventure!

 

Have to ask though - The Cucumber Mask? Or the Masked Cucumber?

 

-Paul

 

Oh i see.....double standards huh?.....it's ok for him to be anonymous.....and wear a disguise even? LOL. Oh the shame, the shame.

[Le Concombre Masqué]

I thank every one of you ; your warm welcomes are warmly appreciated. The Masked Cucumber

[Audio_ELF]

The Masked Cucumber

No relation to The Lone Ranger nor Zorro I assume?

[Paul R]

Hey, I cut you slack all the time - and your moniker is very apt! You might also note how adroitly I avoided agreeing with some his conclusions too. (grin)

 

 

( Just joking, about the moniker I mean... )

-Paul

 

 

Oh i see.....double standards huh?.....it's ok for him to be anonymous.....and wear a disguise even? LOL. Oh the shame, the shame.

[boulderskies]

Respect endianness (relates to file/processor interaction ; further readings might be : The FLAC Audio Format | Start at Zero and aiff). Apple discretely turned AIFF little endian: it matters. FLAC is big endian while Intel processors are little endian. WAV is the uncluttered little endian file format: convert your files to wav just before playing (store flacs for size & tagging). It takes seconds with XLD (Mac) and it’s free (though we should all donate). Yes FLAC offers lossless compression and all your bits are there; but it doesn’t sound as good as AIFF-C and WAV is even better. Because of endianness.

To exit any process that can have a hold on a file, including the Finder, seems best practice.

 

I'm having a hard time getting my head around how the positioning of the bytes could affect sound. Other than one of the articles pointed out that WAV and FLAC do it differently, its not clear. At least to me...

[esldude]

It is all in the magic of bit perfect output sounding different due to endianesses involved upstream boulderskies. (TIC)

[sandyk]

It is all in the magic of bit perfect output sounding different due to endianesses involved upstream boulderskies. (TIC)

 

Don't worry though, use some DSP and it will all sound the same again.(grin)

[Le Concombre Masqué]

I'm having a hard time getting my head around how the positioning of the bytes could affect sound. Other than one of the articles pointed out that WAV and FLAC do it differently, its not clear. At least to me...

 

You don't need to take the time to understand the details of what the guys below are talking about (not audio related, that's an intentional choice) to dig that wrong endianness is wrong computing, period.

 

First Last Prev Next This bug is not in your last search results.

Bug 13409 - windres should specify host endianness for iconv explicitly

[TABLE=class: edit_form, width: 1044]

[TR]

[TD=class: bz_show_bug_column][TABLE=width: 461]

[TR]

[TH=class: field_label, align: right]Status:[/TH]

[TD]RESOLVED FIXED[/TD]

[/TR]

[TR]

[TD=class: bz_section_spacer, colspan: 2][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Product:[/TH]

[TD=class: field_value]binutils[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Component:[/TH]

[TD=class: field_value]binutils[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Version:[/TH]

[TD]2.24 (HEAD)[/TD]

[/TR]

[TR]

[TD=class: bz_section_spacer, colspan: 2][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Importance:[/TH]

[TD]P2 critical[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Target Milestone:[/TH]

[TD]---[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Assigned To:[/TH]

[TD]Not yet assigned to anyone[/TD]

[/TR]

[TR]

[TD=class: bz_section_spacer, colspan: 2][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]URL:[/TH]

[TD][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Keywords:[/TH]

[TD=class: field_value, colspan: 2][/TD]

[/TR]

[TR]

[TD=class: bz_section_spacer, colspan: 2][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Depends on:[/TH]

[TD][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Blocks:[/TH]

[TD]11337[/TD]

[/TR]

[TR]

[TH][/TH]

[TD=colspan: 2, align: left]Show dependency tree / graph[/TD]

[/TR]

[/TABLE]

[/TD]

[TD][/TD]

[TD=class: bz_show_bug_column][TABLE=width: 561]

[TR]

[TH=class: field_label, align: right]Reported:[/TH]

[TD]2011-11-14 11:04 UTC by Yuji Kuwabara[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Modified:[/TH]

[TD]2013-03-27 12:07 UTC (History)[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]CC List:[/TH]

[TD]2 users (show)[/TD]

[/TR]

[TR]

[TD=class: bz_section_spacer, colspan: 2][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]See Also:[/TH]

[TD=class: field_value][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Host:[/TH]

[TD=class: field_value, colspan: 2]FreeBSD, Mac OS X (little-endian)[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Target:[/TH]

[TD=class: field_value, colspan: 2]i386-mingw32msvc (little-endian)[/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Build:[/TH]

[TD=class: field_value, colspan: 2][/TD]

[/TR]

[TR]

[TH=class: field_label, align: right]Last reconfirmed:[/TH]

[TD=class: field_value, colspan: 2][/TD]

[/TR]

[TR]

[TD=class: bz_section_spacer, colspan: 2][/TD]

[/TR]

[/TABLE]

[/TD]

[/TR]

[TR]

[TD=colspan: 3]

---

[/TD]

[/TR]

[/TABLE]

[TABLE]

[TR]

[TD][TABLE]

[TR]

[TH=bgcolor: #E0E0E0, colspan: 2, align: left]Attachments[/TH]

[/TR]

[TR=class: bz_contenttype_text_plain bz_patch]

[TD]Patch against version 2.22 (670 bytes, patch)

2012-06-07 21:32 UTC, Phil Krylov[/TD]

[TD]Details | Diff[/TD]

[/TR]

[TR=class: bz_attach_footer, bgcolor: #E0E0E0]

[TD=colspan: 2]View AllAdd an attachment (proposed patch, testcase, etc.)[/TD]

[/TR]

[/TABLE]

 

[TABLE]

[TR]

[TD]NoteYou need to log in before you can comment on or make changes to this bug.[/TD]

[/TR]

[/TABLE]

[/TD]

[TD][/TD]

[/TR]

[/TABLE]

[TABLE=class: bz_comment_table]

[TR]

[TD]DescriptionYuji Kuwabara 2011-11-14 11:04:49 UTC

 

I installed binutils onto Mac OSX (host, i686 little endian) for mingw32msvc (target, i386 little endian).windres writes resource id and name string (not integer) in big endian into COFF.I investigated a function wind_MultiByteToWideChar() in "winduni.c" .I changed an argument, iconv_open ("UTF-16", iconv_name);to iconv_open ("UTF-16LE", iconv_name);This fixed the problem.Regards.

Comment 1Yuji Kuwabara 2011-11-14 13:04:45 UTC

 

Sorry, these are resource type and resource name (not ID).Regards.

Comment 2Phil Krylov 2012-06-07 21:06:57 UTC

 

Same with version 2.22 of binutils and FreeBSD6.

Comment 3Phil Krylov 2012-06-07 21:32:37 UTC

 

Created attachment 6441 [details]Patch against version 2.22

Comment 4Phil Krylov 2012-06-30 15:45:48 UTC

 

The bug is present in 2.21, 2.22, and 2.23 (HEAD)

Comment 5[email protected] 2013-03-27 11:53:48 UTC

 

CVSROOT: /cvs/srcModule name: srcChanges by: [email protected] 2013-03-27 11:53:46Modified files: binutils : ChangeLog winduni.c Log message: PR binutils/13409 * winduni.c (codepages[]): Use UTF-16LE. (wind_MultiByteToWideChar): Likewise. (wind_WideCharToMultiByte): Likewise.Patches:http://sourceware.org/cgi-bin/cvsweb.cgi/src/binutils/ChangeLog.diff?cvsroot=src&r1=1.2006&r2=1.2007http://sourceware.org/cgi-bin/cvsweb.cgi/src/binutils/winduni.c.diff?cvsroot=src&r1=1.15&r2=1.16

Comment 6Nick Clifton 2013-03-27 11:54:55 UTC

 

Hi Yuji, Hi Phil, Thanks for the bug report. I have applied Phil's patch.heers Nick

Comment 7Phil Krylov 2013-03-27 12:07:11 UTC

 

Thanks, Nick.[/TD]

[TD][/TD]

[/TR]

[/TABLE]

[boulderskies]

You don't need to take the time to understand the details of what the guys below are talking about (not audio related, that's an intentional choice) to dig that wrong endianness is wrong computing, period.

 

[TABLE=class: bz_comment_table]

[/TABLE]

 

Sir, actually I do need to take the time to understand the details of the sources of your first entry on this post. Its the only way I can decide if I agree or disagree with your point about endianess and sound quality or not. So far, I'm not buying it but I am learning a whole lot that I didnt know before and for that, I thank you.

Scott

[boulderskies]

Sir, actually I do need to take the time to understand the details of the sources of your first entry on this post. Its the only way I can decide if I agree or disagree with your point about endianess and sound quality or not. So far, I'm not buying it but I am learning a whole lot that I didnt know before and for that, I thank you.

Scott

 

Well I've done some more reading on endianess and have found nothing that supports the merits of big-endianess vs little-endianess and vice versa. It seems they are basically different memory formats based on the processor type (not machine) the software was originally designed to run on. And any reference to sound quality is purely subjective. I wonder if anyone on here knows of any documentation which might support superior SQ with one over the other.

Its really interesting stuff though.

Scott

[Audio_ELF]

Well I've done some more reading on endianess and have found nothing that supports the merits of big-endianess vs little-endianess and vice versa. It seems they are basically different memory formats based on the processor type (not machine) the software was originally designed to run on. And any reference to sound quality is purely subjective. I wonder if anyone on here knows of any documentation which might support superior SQ with one over the other.

Its really interesting stuff though.

Scott

I believe the argument is that using a big-endian file format on a little-endian OS (or vice versa) requires additional processing which can affect SQ.

 

Please don't shoot the messenger for writing this - I'm only saying what the argument is.

[boulderskies]

I believe the argument is that using a big-endian file format on a little-endian OS (or vice versa) requires additional processing which can affect SQ.

 

Please don't shoot the messenger for writing this - I'm only saying what the argument is.

Thank you. I didnt pick that up.

[Paul R]

As Audio_ELF said, it is, in theory, the additional processing needed to swap the bytes around that could - again in theory - cause an audible difference. There is some evidence for this making an audible difference, and there is some evidence against it making any difference at all.

 

I suspect, but have not done the work to absolutely prove, that using a powerful computer (i.e. an i7 or thereabouts) probably means you will not see any difference between big and little endian data. Using a "just powerful enough computer", such as an Atom based netbook, makes it far more likely you might hear sonic differences between big and little endian data. Using a streaming device virtually eliminates the issue, since at least in most cases, binary data is converted to "Network Order" before transmission anyway.

 

None of this is all that complex when taken by itself, but when combined into a typical audiophile environment, the sheer number of factors to consider can make it appear more than a little complex. If you look at it the right way though, it can sure be a lot of fun to experiment and discover what does and does not make a difference in your particular system!

 

-Paul

 

 

Well I've done some more reading on endianess and have found nothing that supports the merits of big-endianess vs little-endianess and vice versa. It seems they are basically different memory formats based on the processor type (not machine) the software was originally designed to run on. And any reference to sound quality is purely subjective. I wonder if anyone on here knows of any documentation which might support superior SQ with one over the other.

Its really interesting stuff though.

Scott

[boulderskies]

As Audio_ELF said, it is, in theory, the additional processing needed to swap the bytes around that could - again in theory - cause an audible difference. There is some evidence for this making an audible difference, and there is some evidence against it making any difference at all.

 

I suspect, but have not done the work to absolutely prove, that using a powerful computer (i.e. an i7 or thereabouts) probably means you will not see any difference between big and little endian data. Using a "just powerful enough computer", such as an Atom based netbook, makes it far more likely you might hear sonic differences between big and little endian data. Using a streaming device virtually eliminates the issue, since at least in most cases, binary data is converted to "Network Order" before transmission anyway.

 

None of this is all that complex when taken by itself, but when combined into a typical audiophile environment, the sheer number of factors to consider can make it appear more than a little complex. If you look at it the right way though, it can sure be a lot of fun to experiment and discover what does and does not make a difference in your particular system!

 

-Paul

 

I couldnt agree more with your last paragraph.

 

What I have logical problems with are statements of subjective opinion (based on albeit technically valid concepts) being expressed as if they are concrete and verifiable facts.

[Le Concombre Masqué]

I couldnt agree more with your last paragraph.

 

What I have logical problems with are statements of subjective opinion (based on albeit technically valid concepts) being expressed as if they are concrete and verifiable facts.

 

Hello Paul & Scott and al,

 

this is very particular system (and room) specific but you sure can measure the effect of endianness as concrete and verifiable. Sometimes it's, i.e., clearer and faster snares and cymbals ; but in an instance where the impact was heavier bass I could, with right endianness (processor dependent, little endian for PC and Intel Mac) at a certain level, in 100% of the tries, lit the mid charge led of my right sub amp at x second and get y piece of furniture to resonate while not with the wrong endianness file.

 

Anyway, converting to wav is free and fast can be done just before listening and you may/should keep archiving flac or aiff.

 

Beware of streaming if it keeps your processors active while playing a track...

 

cheers, TMC

[boulderskies]

Hello Paul & Scott and al,

 

this is very particular system (and room) specific but you sure can measure the effect of endianness as concrete and verifiable. Sometimes it's, i.e., clearer and faster snares and cymbals ; but in an instance where the impact was heavier bass I could, with right endianness (processor dependent, little endian for PC and Intel Mac) at a certain level, in 100% of the tries, lit the mid charge led of my right sub amp at x second and get y piece of furniture to resonate while not with the wrong endianness file.

 

Anyway, converting to wav is free and fast can be done just before listening and you may/should keep archiving flac or aiff.

 

Beware of streaming if it keeps your processors active while playing a track...

 

cheers, TMC

 

This is what I call the "Scientific Method" (very humorous-thanks for the laugh):

...little endian for PC and Intel Mac) at a certain level, in 100% of the tries, lit the mid charge led of my right sub amp at x second and get y piece of furniture to resonate while not with the wrong endianness file.

[Paul R]

I think most people would call it empirical evidence from a credible witness, and empirical evidence is most certainly part of the scientific method.

 

Indeed, some form of empirical evidence is always required for any hypothesis to gain traction in the scientific community. Of course there is a lot more rigorous process involved further down the line, but empirical evidence is required near the beginning of the process for it to even proceed.

 

So you might consider taking a more positivist attitude here, and applaud those who are attempting to provide empirical evidence to support their theories, even where you disagree with the theory and or interpretation of the evidence

 

-Paul

 

 

 

This is what I call the "Scientific Method" (very humorous-thanks for the laugh):

...little endian for PC and Intel Mac) at a certain level, in 100% of the tries, lit the mid charge led of my right sub amp at x second and get y piece of furniture to resonate while not with the wrong endianness file.

[Le Concombre Masqué]

This is what I call the "Scientific Method" (very humorous-thanks for the laugh):

...little endian for PC and Intel Mac) at a certain level, in 100% of the tries, lit the mid charge led of my right sub amp at x second and get y piece of furniture to resonate while not with the wrong endianness file.

 

Yes, it's very scientific to, repeatedly, see or not a led lit or witness or not a resonance ; but maybe you haven't spent any time in any lab. Though it's not quantitative it qualifies a difference.

 

I wrote my note to help. If you enjoy scientific measures, record spectros of wrong and right endianness files played on a high end system in a controlled room and compare the curves at different precisely controlled times.

 

Or just listen

[boulderskies]

I think most people would call it empirical evidence from a credible witness, and empirical evidence is most certainly part of the scientific method.

 

Indeed, some form of empirical evidence is always required for any hypothesis to gain traction in the scientific community. Of course there is a lot more rigorous process involved further down the line, but empirical evidence is required near the beginning of the process for it to even proceed.

 

So you might consider taking a more positivist attitude here, and applaud those who are attempting to provide empirical evidence to support their theories, even where you disagree with the theory and or interpretation of the evidence

 

-Paul

 

Point taken.

But if you go back to the original post, the link between endianness, codecs and SQ was stated much more emphatically than "theory" or empiricism. That's what drew my natural skepticism (I that healthy, not negative). Cucumber's second post was much more empirical.

And yes, of course, I applaud his attention to detail and thoughtfulness in sharing his experiences with us. I learned a lot, which is always important.

[Paul R]

Yes, I see your point. But remember, not everyone here is a rationalist scientist. Heck, not everyone here even speaks English all that well. Let's all cut each other a little slack.

 

Heck, might be fun to try that...

 

"Changing this parameter repeatedly caused a room resonance. I believe this is evidence to support the hypothesis that byte order within a stream of music data can cause an audible effect through some unknown -at this time- mechanism"

 

in French, I would most likely say it like this, even though I know it is at least a moderately inaccurate translation of the English statement above:

 

La modification de ce paramètre a provoqué une résonance de la pièce à chaque fois que j'ai modifié le paramètre. Je crois que c'est la preuve de l'hypothèse que l'ordre des octets dans un flux de données musicales est un effet sonore. Le mécanisme est inconnue pour moi en ce moment.

 

The French was MUCH more difficult for me to write than the English statement. Indeed, I am not sure it is correct even now... darn it.

 

-Paul

 

P.S. That was only an example, I did not intend to promote that hypothesis!

 

Point taken.

But if you go back to the original post, the link between endianness, codecs and SQ was stated much more emphatically than "theory" or empiricism. That's what drew my natural skepticism (I that healthy, not negative). Cucumber's second post was much more empirical.

And yes, of course, I applaud his attention to detail and thoughtfulness in sharing his experiences with us. I learned a lot, which is always important.