APV, visually lossless pro codec from Samsung

[benwaggoner]

If we ignore that, which is impossible in real world, but just imagine... the generational loss isn't terrible actually, to me at least.
Still not as good as QAAC.
But as we all know, AAC encoders have a vast quality range. And good AAC encoders ain't free and open source.
I tested QAAC, ffmpeg aac_at (by audiotoolbox wrapper, and is using same DLLs as QAAC), ffmpeg libfdk_aac and ffmpeg aac, QAAC is the only one that's better than "Opus minus low freq".
(The QAAC test is using QAAC for both decode and encode)
Yeah, back in the IMA standard we found that sufficiently high AAC-LC bitrates were sufficient quality for mezzanines (I think using Apple's encoder). Fortunately audio bitrates are low enough that lossless compression is generally viable.

[GeoffreyA]

Opus' preproecssing hitting hard. :p

Yes, 20 KHz cutoff shouldn't make noticable difference, but when I compared the spectrogram (1st encode), I noticed that there seem to be some kind of processing on the low frequency side as well, maybe it's the < 20 Hz hearing limit, similar to the 20 KHz cutoff, or a design flaw / limitation.

It's doesn't matter for probably a few cycles, but when the cycle progress, it gets progressively weirder, making the low-frequency instruments sound like, idk, wind, somehow? Even at maximum bitrate.
This terrible generational loss is "gone" if I delete the < 100 Hz frequency.

If we ignore that, which is impossible in real world, but just imagine... the generational loss isn't terrible actually, to me at least.
Still not as good as QAAC.
But as we all know, AAC encoders have a vast quality range. And good AAC encoders ain't free and open source.
I tested QAAC, ffmpeg aac_at (by audiotoolbox wrapper, and is using same DLLs as QAAC), ffmpeg libfdk_aac and ffmpeg aac, QAAC is the only one that's better than "Opus minus low freq".
(The QAAC test is using QAAC for both decode and encode)
EDIT: turns out I screwed the aac_at test, the pre-skip ruined it very bad.

Oh there's an experimental ffmpeg native Opus encoder, I tested it and... somehow it has low generational loss comparable to QAAC (still worse).
But the problem is, it's experimental, who knows what else can happen.

When Opus degrades, it sounds strange, probably because CELT works a bit differently from the classic MPEG codecs.

So the processing in the low-frequency end is being amplified from repeated encoding. I wonder if they tested this case. Perhaps FFmpeg's native Opus encoder is doing less, incidentally helping here.

I was surprised how well AAC held up. I've got the script somewhere. We can encode some samples and have at it for science.

Yeah, back in the IMA standard we found that sufficiently high AAC-LC bitrates were sufficient quality for mezzanines (I think using Apple's encoder). Fortunately audio bitrates are low enough that lossless compression is generally viable.

Apple's AAC-LC encoder is excellent. I use QAAC for music and encoding films. Usually, TVBR 91 or 109.

[Z2697]

Here's my Python script for repeated encoding, designed to run in a dedicated folder, with a source file named in numbers (ideally, 0000) that it can recognize.
I used "nut" container because why nut ;) But that's how the pre-skip, or more precisely the lack thereof, ruined the aac_at test. Please change that accordingly.
(terrible coding style, isn't it)

import subprocess
import pathlib
sp=pathlib.Path(__file__).parent.absolute()
files=[i for i in sp.glob('*') if i.stem.isnumeric()]
files.sort(key=lambda x:int(x.stem))
i=int(files[-1].stem)
while i<50:
i+=1
newfile=sp/f'{i:04d}.nut'
subprocess.run(f'ffmpeg -i "{files[-1]}" -c:v libx264 "{newfile}"')
files.append(newfile)
input(f'{i} encodes finished.')

I do more than 50 cycles, usually. But that's just a template.

[GeoffreyA]

Why nut? :)

As for me, I don't know Python, so it looks a bit alien. If I were younger, I'd have done it in C++ but have grown rusty and lazy. Last year, I made a simple Windows batch file, and now tidied it up with some variables before posting:

setlocal
set qaac=D:\tmp\qaac\qaac64
set bitrate=128

"%qaac%" --cvbr %bitrate% a.wav

for /l %%x in (1, 1, 100) do (

ffmpeg -y -i a.m4a -c:a pcm_f32le tmp.wav
"%qaac%" --cvbr %bitrate% tmp.wav -o a.m4a

)

endlocal

[Z2697]

Why nut? :)

As for me, I don't know Python, so it looks a bit alien. If I were younger, I'd have done it in C++ but have grown rusty and lazy. Last year, I made a simple Windows batch file, and now tidied it up with some variables before posting:

setlocal
set qaac=D:\tmp\qaac\qaac64
set bitrate=128

"%qaac%" --cvbr %bitrate% a.wav

for /l %%x in (1, 1, 100) do (

ffmpeg -y -i a.m4a -c:a pcm_f32le tmp.wav
"%qaac%" --cvbr %bitrate% tmp.wav -o a.m4a

)

endlocal

Since I use VapourSynth, Python is always a thing at hand, so I just went for it.
C++ will be an overkill.
BTW, QAAC can read M4A, re-encode AAC to AAC directly.

[GeoffreyA]

Since I use VapourSynth, Python is always a thing at hand, so I just went for it.
C++ will be an overkill.
BTW, QAAC can read M4A, re-encode AAC to AAC directly.

I also use VapourSynth but basic scripting, so it's understandable. I find VS scripts more readable than AviSynth.

Yes, that's right. The script needs to be generalised to work with LAME, Opus, or any encoder. Right now, one has to change the commands manually, which is error prone.