AIFF Vs. WAV

[soooowhat]

thanks Miska, for the clarification

 

so, if the theory that additional processing could add noise and detract from playback quality holds true, AIFF and Intel architectures are a bad combination, and AIFF-C is also a crap shoot with Intel, but at least has a chance of better matching.

 

Now to find an OS X ripper than is configurable.

 

 

 

 

 

 

 

 

[Miska]

I just used the "get info" command on the file on the disc where my music is stored.

 

If you are really getting AIFF-C/sowt files from iTunes, then we probably cannot expect any consistent behavior from iTunes...

 

In case it is AIFF-C/sowt, then in your case we can rule out byte swapping from the list of possible reasons for any differences to WAV, since the audio data stored in a file should be identical.

 

In HQPlayer both AIFF and WAV are handled by the very same piece of code, only difference being that for AIFF, one extra CPU clock cycle per sample is spent on swapping the bytes. Which means 0.00138% more CPU load on my 3.2 GHz dual core CPU... (moving mouse pointer around takes more)

 

Of course other pieces of software may have completely different code for handling AIFF and WAV and thus could have fairly large differences on CPU usage patterns.

 

 

[4est]

"If you are really getting AIFF-C/sowt files from iTunes, then we probably cannot expect any consistent behavior from iTunes..."

 

I do not understand Miska, please excuse my ignorance. Would it be labeled AIFF C if it were not? Consistent behavior? Every file I have looked at (only a handful-10 to 12) was AIFF C. This is using OSX 10.6 and iTunes 10.3 IIRC, not the latest as I hear others are having issues with it. Besides, some of my experiments were done a year ago.

 

[Paul R]

Appreciate it.

 

I'm not sure the Get Info out of iTunes can be totally trusted. I think it is smoothing over some of the information to be more user friendly. (*sigh*)

 

The processing needed to swap bytes is of course, very minor indeed. But I have no idea how much further byte swapping goes on. I know the processing uses floats, and I think the USB transmission requires network order transmission. That means an initial swap, transmission to the drivers, processing, and yet another swap to put it out on the USB buss.

 

Somewhere in all that is, I think, a reasonable explanation for the difference that is being heard. A calibrated set of ears can sometimes detect really minute differences, especially in timing.

 

-Paul

 

 

 

[soooowhat]

He's pointing to the fact that he got AIFF big-endian from iTunes, and you are getting AIFF-C.

 

OTOH, looks like you're using an older version.

 

 

 

[4est]

I am only one version behind... I wanted to make sure that it wasn't just big/little endian we were talking about.

 

Paul: We shouldn't assume USB. I (and some others) noticed this using a Firewire device. I have an M2Tech Evo that I am using via i2s that I will have to do (yet another) check with.

 

Is there another way to check AIFF type that a simpleton such as myself should perform?

 

[4est]

Awhile back a poster here asked me to give the file length info for a couple of tracks. These were just imported during this thread. I do not know what he was getting at, but here it is in case it helps

 

The Waifs

Track 2: "Nothing New"

 

wav = 37,523,852

aiff c = 37,526,064

 

Johanna Grussner

Track 8: "First Time Ever I saw Your Face"

 

wav = 60 954,476

aiff c = 60,956,748

 

[Paul R]

That is an excellent point indeed. Yet more questions without good answers. I like that. I expect S/PDIF has a transmission protocol definition for byte order as well, but it is definitely one more thing to check out.

 

As for more certain ways to determine byte order, I think the method Miska described is perhaps the most accurate, and it's also pretty easy, though you find yourself typing a couple arcane incantations.

 

It's too darn early to get excited, and we don't have near enough facts yet. I am hoping perhaps Bill will duplicate this and be able to verify he can hear a difference. If that happens, perhaps we can hit Barry or someone up for a 20 second clip of some music we can put into different formats and redistribute. Then everyone can be let in on the fun.

 

I sure would like it if this group found, solved, and documented a real mystery like this.

 

-Paul

 

 

 

 

[ted_b]

endian. These are what are compared less favorably to wav, in all my posts. I convert them via DB Poweramp (some came from FLAC and some were never converted from original AIFF). I have seen AIFF-C files and know what they are (my DSDIFF converters all ask if you want them) but don't play them and db poweramp doesn't support them.

 

[ted_b]

18 months, some firewire (Metric Halo, Orpheus, Steinberg, etc), some USB (Antelope, Ayre, Wavelength, M2tech, etc), some SPDIF and AES (Berkeley, Forssell, etc). I do the WAV/FLAC/AIFF thing to each of them (one of the tests) and it is consistent across these vehicles. In some cases, where the DAC was less resolving, so were the differences....of course.

 

[4est]

...to listen to music instead of mowing the lawn!

 

[GB]

"Please send private messages if you feel you need to attack each other"

Chris, I didn't mean to attack anybody. I simply can't understand, how to decide which reproduction is better without base of comparison. "Less harsh, micro, macro..." Maybe it was made harsh intentionally? If some scene of the movie was shot in a fog, would you like the player, that removes that fog and makes the picture more clear? The movie director didn't have this in mind...

 

[wgscott]

What should I be doing? Sorry if I dropped the ball, but I don't know where to begin...

 

[Miska]

I expect S/PDIF has a transmission protocol definition for byte order as well, but it is definitely one more thing to check out.

 

Sure it has, just like I2S, but in most cases both are handled by the hardware. And perform the same way always.

 

I use mostly PCI and PCIe interfaces and these use native (little) endian byte order. And once the data is placed in computer's RAM, it is read out from there by the interface based on it's own sample clock. For USB, I don't know what order is used by M2Tech hiFace, they could use what ever they want since it's custom protocol.

 

But important thing to note is that I'd expect most players to have always the same code towards the audio interface regardless of input format and it's endianess. So the difference should be somewhere on the file handling side. Thus, would be interesting to hear if someone compared differences of different formats between different player applications...

 

 

[PeterSt]

Miska, your simple byte swap does loads more than just swapping two bytes. Your 0.000xwhatever % additional cpu load coming from that doesn't look right to me either.

 

Just make an empty loop and see how long it can become before your % is reached.

 

I didn't read the whole thread, but what happened to your "no noise PC" ever lasting story ? If it's in here, I didn't say that, but it sure looks like you are suddenly enthusiast about this ?

And this, while I managed to follow your strategy at last ?

haha

No, I won't eleborate further. I tried a few days back, but my post got deleted. Nothing wrong with that by itself, but now we can keep on being nicely intrigued. Ok, some. Or most.

 

Well, at least I am.

 

But for a small recap, avoiding reading all the thread ...

Must we assume the noisy environment ?

 

Regards,

Peter

 

[Miska]

Miska, your simple byte swap does loads more than just swapping two bytes. Your 0.000xwhatever % additional cpu load coming from that doesn't look right to me either. Just make an empty loop and see how long it can become before your % is reached.

 

There's data conversion loop always, only difference is that the big-endian variant adds single register-to-register assembly instruction to the loop. For most parts, I know fairly well how many clock cycles are spent where.

 

I didn't read the whole thread, but what happened to your "no noise PC" ever lasting story ? If it's in here, I didn't say that, but it sure looks like you are suddenly enthusiast about this ?

 

I don't hear any difference between FLAC/ALAC/WAV/AIFF in my system, but I'm naturally interested on tracking down the exact point where someone else with some other piece of software is hearing a difference. No, I'm not more enthusiastic about it now than I've been before. I just want to track down it in scientific way, since I truly hate any "it's just there" -hands waving, without real attempt to track down and nail it.

 

P.S. These days I'm running the software also on 1 GHz ARM CPU, not only PC...

 

 

[PeterSt]

I don't hear any difference between FLAC/ALAC/WAV/AIFF in my system, but I'm naturally interested on tracking down the exact point where someone else with some other piece of software is hearing a difference

 

Ah good.

 

Maybe it has been said already, but possibly it can be so that in systems where the byte order can be offered to the OS' kernel audio engine(s) in a transparent fashion (but indicated by the header of course), from there on it all being out of our (player's) hands and things will have an own life (of overhead etc.). I am not sure this can be the case on a Mac, but thinking of the past if can well be that solutions (in the OS) exist to make it all transparent to the user (where all before depended on Big Endian). This is not so in Windows, or at least not with the lower level engines (Kernel Streaming, or WASAPI as a derival from that). Direct Sound maybe; I never tried that.

 

What probably not has been said in this thread, is that we often have to think the other way around from what seems natural;

When things sound better, this is most often because MORE processing is applied (but think current draw). That works as a filter, depending on the frequency. The best example is the SSD, of which people long time (eh still do) thought that it produces the better sound. Well, it really does not. There is no reason to, while many reasons for the other way around exist.

This is not about SSD's (so let's let the subject out), but it is THE example where people perceive better sound because a filter being at work. That this implies that other forces are at work first (noise leaking through) is another matter, but also THE matter. All I want to say is : for those where e.g. AIF sounds better it does not mean at all that for their system "thus" there's less processing. It can very well be the other way around. In fact it can go either way (sadly).

But good to keep in mind.

 

Peter

 

[Jim Smith]

I believe the posters who hear a difference.

 

I tried to hear it, thought that maybe I did for a while, but couldn't repeat it. Only used my system for the tests.

 

So here's another post in the "I don't hear a difference" camp.

 

[Miska]

When things sound better, this is most often because MORE processing is applied (but think current draw). That works as a filter, depending on the frequency.

 

How would the filter-effect be technically realized if the audio hardware and it's clocking is properly isolated from the CPU? In any case, it is then just about fixing the hardware...

 

Measuring ripple on PSU lines and noise on data lines is fairly easy task.

 

 

[Paul R]

Thanks Miska - just to be sure I am asking the right question, these protocols are sensitive to byte order in their streaming? I'm a little surprised they would stream in little endian format.

 

I rather expected network order, which is big endian. Little endian would make more sense in the context of the current discussion though. I think.

 

-Paul

 

 

[Paul R]

@ WGScott

 

LOL! You didn't drop any ball, I was probably confused. If you could, would you try playing the same track on your system as a WAV, a Big Endian AIFF, and a Little Endian AIFF file?

 

I'll stick my neck out a mile or two here and make some predictions. Won't break my heart if they are wrong though. Just a loose as ashes theory.

 

On a Mac with Lion and an i3/i5 process --- won't be able to hear any differences from iTunes/Amarra/PM/Fidelia/BitPerfrect

 

On a Mac with Lion and a Core2 Duo processor - will hear differences from Fidelia, and possibly from iTunes/Amarra. Upsampling systems will mask the difference, if it exists.

 

To create a little endian AIFF, you will probably have to convert a file to PCM and then to little Endian AIFF, using XLD.

 

-Paul

 

P.S. --> Any results, including totally negative results, will be helpful.

 

 

[goldsdad]

For brevity, I'll use BE for big-endian and LE for little-endian.

 

XLD, Max, iTunes, Audacity, Wave Editor and afconvert can create AIFF BE, but not AIFF LE.

It seems to be tricky to find a Mac app that'll create AIFF LE.

 

If you want to compare BE and LE variants of one format, then CAFF can be played by Decibel, Fidelia, QuickTime Player, afplay and probably others too.

afconvert can create CAFF BE and CAFF LE.

 

afconvert -f caff -d BEI16 example.wav example_BE.caf

afconvert -f caff -d LEI16 example.wav example_LE.caf

 

afconvert -f caff -d BEI24 example.wav example_BE.caf

afconvert -f caff -d LEI24 example.wav example_LE.caf

 

 

 

 

[Paul R]

I know that XLD can create raw PCM data in both byte orders, I had thought you could create a little endian AIFF file with it, but now I am not so sure.

 

Does anyone have an un-encumbered music clip we could create the files with and redistribute to folks here? Some kind of a test file or something?

 

-Paul

 

 

 

[Miska]

Thanks Miska - just to be sure I am asking the right question, these protocols are sensitive to byte order in their streaming? I'm a little surprised they would stream in little endian format. I rather expected network order, which is big endian. Little endian would make more sense in the context of the current discussion though. I think.

 

Since all are serial data formats, they are sensitive to bit order.

 

I2S is MSB first

S/PDIF is LSB first.

 

However, since the serialization is done by hardware, byte order is usually what is native to the system and hardware handles correct bit sequencing. Thus, for example most PCI/PCIe interfaces use 32-bit little-endian words (32-bit because DMA is always 32-bit aligned). And for example most S/PDIF receivers and transmitters handle I2S, so they rearrange the data - that's their function anyway.

 

 

[goldsdad]

What about asking Barry D and Cookie M. They have some free downloads which they might allow to be used for these tests.