Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Is QAAC and the Apple Encoder all CPU? (Read 5526 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is QAAC and the Apple Encoder all CPU?

I installed foobar2000, the encoder pack and the Apple Application Support MSI in Wine on Linux.  Everything seems to work just fine.  I can load in any FLAC file and encode it into an m4a AAC file without issue.  Wine is an emulator that allows you to run native Windows apps on Linux natively.

My question is, is doing this through wine on Linux going to produce a file different from doing it on Windows natively?  Could it be inferior in any way?

For that matter, is there any difference between the Apple's AAC encoder on the Mac vs, Windows?

Is QAAC and the Apple Encoder all CPU?

Reply #1 –
Strictly speaking, Wine Is Not an Emulator. It is a Windows layer (including linux implementation of system dlls, understanding of windows file and directory paths, registry, and so on).

Knowing that, it is clear that the code that will run is not exactly the one that would run on a windows machine ( but it wouldn't be the same probably  between a Windows 2000 and a Windows 8 machine either).

For what is worth, the foobar code, the qaac code (which i assume that is what you use to call the Apple's codec), and the Apple's code is the same. The only thing that changes are the Operating system actions, like writing to a file, or how threads are run.

So, with all that, I don't expect any difference in the bits produced by it running on windows *on the same machine* than running on Wine.

Is QAAC and the Apple Encoder all CPU?

Reply #2 –
^^^ Interesting.

To add, it's conceivable you might end up with encodes that aren't bit-for-bit identical due to hardware or compiler differences. You know, not every hardware rounds exactly the same and there might be hardware-specific bugs (although it's probably fairly unlikely you run into relevant hardware bugs which aren't addressed in software). Perhaps more importantly, different compilers, different compiler flags, and tuning for different hardware platforms in a given compiler might result in codec binaries which don't produce bit-for-bit identical AAC files.

Is QAAC and the Apple Encoder all CPU?

Reply #3 –
Quote from: audiophool on
^^^ Interesting.

To add, it's conceivable you might end up with encodes that aren't bit-for-bit identical due to hardware or compiler differences. You know, not every hardware rounds exactly the same and there might be hardware-specific bugs (although it's probably fairly unlikely you run into relevant hardware bugs which aren't addressed in software). Perhaps more importantly, different compilers, different compiler flags, and tuning for different hardware platforms in a given compiler might result in codec binaries which don't produce bit-for-bit identical AAC files.


This is true.

From what I have read on the wiki and other sources, the Apple encoder seems to be the best, followed by the fraunhoffer.  The one that normally ships with Linux, FAAC, is considered far inferior to the others.  So, if I'm going to make AAC files on Linux, this seems to be the only acceptable route to go.

If I could get the iDevices in my house out of the equation, I'd just rip to ogg vorbis and be done with it.

Is QAAC and the Apple Encoder all CPU?

Reply #4 –
You might also be able to experiment with FFMPEG and the libfdkaac . That's the free fraunhoffer code.

Is QAAC and the Apple Encoder all CPU?

Reply #5 –
Quote from: audiophool on
^^^ Interesting.

To add, it's conceivable you might end up with encodes that aren't bit-for-bit identical due to hardware or compiler differences. You know, not every hardware rounds exactly the same and there might be hardware-specific bugs (although it's probably fairly unlikely you run into relevant hardware bugs which aren't addressed in software). Perhaps more importantly, different compilers, different compiler flags, and tuning for different hardware platforms in a given compiler might result in codec binaries which don't produce bit-for-bit identical AAC files.

I've wondered why Windows iTunes Plus isn't bit identical to Mac iTunes Plus for the same iTunes version.  Also last time I tried, I couldn't get identical QAAC iTunes Plus to Windows iTunes Plus (using QAAC -v256 -q2).  Maybe just me.

Is QAAC and the Apple Encoder all CPU?

Reply #6 –
Quote from: wottha on
I've wondered why Windows iTunes Plus isn't bit identical to Mac iTunes Plus for the same iTunes version.

The result of floating point math is different when different compiler is used.
You can observe the very same situation on LAME, FLAC, Vorbis or something. It's common thing.
Quote
Also last time I tried, I couldn't get identical QAAC iTunes Plus to Windows iTunes Plus (using QAAC -v256 -q2).  Maybe just me.

Current qaac doesn't generate bit-identical stream as iTunes unless --no-smart-padding is specified.
https://github.com/nu774/qaac/wiki/FAQ#q7
Quote
Try --no-smart-padding. qaac by default applies smart padding by extrapolating the beginning/ending of the input, in order to avoid glitches between songs on gapless playback.

Is QAAC and the Apple Encoder all CPU?

Reply #7 –
Is there a real need for smart padding? Ive never had any problems or have i read of any problems with itunes gapless encodes.

Is QAAC and the Apple Encoder all CPU?

Reply #8 –
Quote from: sluggy on
Is there a real need for smart padding? Ive never had any problems or have i read of any problems with itunes gapless encodes.

I found tiny but audible glitch on a sample with lower bitrate setting (it was SBR) for both of Apple AAC and FDK AAC, that's why I implemented smart padding borrowed from Vorbis/Opus.