ffmpeg developer: "Using <extremely common use case> is invalid to prove anything." Why do I even waste my time on this?https://twitter.com/BMahol/status/1255867904475750401 …
-
-
Just to be clear, he's referencing this thread where I provided all the info requested with a testcase (but he replied to the wrong thread).https://twitter.com/marcan42/status/1255778661942231040?s=19 …
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
The two replies from the ffmpeg account in that thread seemed reasonable. Maybe supply the info and see if they take it seriously?
-
I did, see my previous tweets. That reply from an ffmpeg developer is referencing those (but he replied to the wrong thread).
- Show replies
New conversation -
-
-
Makes me wonder if it'd be possible to have some kind of metadata that aligns the block positions as to match the source file

-
It's the same source file, with the same alignment. It still completely murders the audio after just 4 generations at 128k.
End of conversation
New conversation -
-
-
Can you modify the code to remove the defect, or is that too much work? Being able to A/B comparison it would probably be more clear.
-
I'm not an audio codec dev and I know nothing about AAC; it would take quite a while to get up to speed in that field to be able to contribute.
- Show replies
New conversation -
-
-
I wonder if a randomized comparison test could be used to quantify psychoacoustic loss? Basically, at a given bitrate, what percentage of human listeners can correctly identify the compressed vs. uncompressed sample side by side?
-
And then, presumably, at the same bitrate, does a competing implementation have a better or worse result on the same test?
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.