Changes between Initial Version and Version 1 of Ticket #8066, comment 13
- Timestamp:
- May 5, 2020, 12:19:17 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #8066, comment 13
initial v1 5 5 For what it's worth, libfdk_aac seems to be exceptionally stable. At 100 repeat encodes at 128kbps, it still produces listenable output, with somewhat patchy high frequency bands but otherwise no added distortion nor level changes. I would subjectively rate it on par with ffmpeg-aac after just 6 transcodes. At that point ffmpeg-aac has more high frequency content, but also has more audible *added* noise/artifacts. Those add up to complete destruction by the time you get to 100 transcodes. Sure, 100 transcodes is a silly use case, but the results still sound like they should lead to some insight as to how to improve the encoder. 6 6 7 Also, consider that already encoded audio is perfectly valid PCM after decoding, and a useful sample to test encoding on. While there are subtleties regarding whether an encoder encoding its own output would have an advantage vs encoding another encoder's output (or another dodec's entirely), this is still not a test to be dismissed on the face of it. This whole thing started for me because a practical MP3 (256k) -> ffmpeg-aac (320kbps) -> ffmpeg-aac (320kbps) pipeline had noticeably worse artifacts than replacing just the last step with libfdk_aac at the same bitrate, or even at 128kbps. I posit that 320kbps should be effectively transparent for essentially all samples, and should remain so even after a few transcodes. The sample that started this all is not transparent for me after just 2 rounds of ffmpeg-aac at 320kbps (>99% confidence), but is after 100 rounds of libfdk_aac at the same bitrate.7 Also, consider that already encoded audio is perfectly valid PCM after decoding, and a useful sample to test encoding on. While there are subtleties regarding whether an encoder encoding its own output would have an advantage vs encoding another encoder's output (or another codec's entirely), this is still not a test to be dismissed on the face of it. This whole thing started for me because a practical MP3 (256k) -> ffmpeg-aac (320kbps) -> ffmpeg-aac (320kbps) pipeline had noticeably worse artifacts than replacing just the last step with libfdk_aac at the same bitrate, or even at 128kbps. I posit that 320kbps should be effectively transparent for essentially all samples, and should remain so even after a few transcodes. The sample that started this all is not transparent for me after just 2 rounds of ffmpeg-aac at 320kbps (>99% confidence), but is after 100 rounds of libfdk_aac at the same bitrate. 8 8 9 9 Just to add some relevant references:
