I've got an idea from 'Mastered for iTunes' droplet:
Apple’s latest encoding methodology is a two-step process. The first step in the encoding path is to use state-of-the-art, mastering-quality Sample Rate Conversion (SRC) to resample the master file to a sample rate of 44.1kHz.
Because this SRC outputs a 32-bit floating-point file, it can preserve values that might otherwise fall outside of the permitted amplitude range. This critical intermediary step prevents any aliasing or clipping that could otherwise occur in SRC. It is this 32-bit floating file that’s used as the input to the encoder and is one key reason for such stunning results.
Our encoders then use every bit of resolution available, preserving all the dynamic range of a 24-bit source file and eliminating the need for dithering. The advantage of this is twofold. Not only does it obviate the need of adding dither noise, it also lets the encoders work more efficiently as they don’t need to waste resources encoding this unwanted and unnecessary noise.
By using this highly accurate file directly from our SRC and taking advantage of its clean signal, our encoder can deliver the final product exactly as the artist and sound engineers intended it to sound.
So I'm doing this:
afconvert <in.aif> -d LEF32@48000 -f WAVE --src-complexity bats -r 127 <out.wav>
opusenc --bitrate 128 <in.wav> <out.opus>
Source is 96/24 from HDtracks.
The result is fantastic and indistinguishable from the source, I'm just wondering is this intermediate step/method sane or if it's even doing anything to improve the input for opusenc to work with?
The resampler which is used by opusenc internally is already good enough, the difference is likely in the placebo area.
If you just use opusenc with this input directly, you'll probably still get the result which is fantastic and indistinguishable from the source.
I've got an idea [that the people who wrote my encoder do not understand how precision works] from 'Mastered for iTunes' droplet
You're not going to outsmart the people who wrote the codec by reading some marketing bullshit. Just not going to happen.
In this case, the resampler used in Opus operates in floating point precision normally (unless compiled for a target with no floating point support). However this actually doesn't matter very much, and the integer version of the Opus resampler also works great. That Apple quote is really misleading, even nonsensical. The advantage of giving Apple floating point data is that if the artist is too inept to set the levels correctly, Apple can fix that before it clips. If you take clipped audio data and convert to floating point, it doesn't help because the data is already clipped.
Thanks for the info, I was mainly interested about the 32-bit floating point stuff and how it might be relevant.