[Libav-user] Audio quality loss while encoding

[Brad O'Hearne]

On Apr 30, 2013, at 3:09 PM, Kalileo <kalileo at universalx.net> wrote:

> Brad, that the problem with what you spread here

I spread *nothing*. Here's the exact statement from Paul Mahol, presumably one of the developers on the list. 

> Note that native aac encoder is experimental and mostly useless.

If you feel the AAC encoder is *not* mostly useless (I have no idea, I"m just listening to those in the know), then take it up with Paul. My point is what would be the point of leaving "mostly useless" code in the codebase. If someone else finds use for it, great -- then the assertion that it is "mostly useless" is what you should be taking issue with. If it is of great use, then awesome, don't leave it in. 

> , you elaborate and theorize about your problems, and propose fundamental changes to ffmpeg, but all based on some unsystematic experiments, assumptions and half-theories. And at the end the problem is never in ffmpeg.

That is completely irrelevant to the issue of whether leaving a dead codec (if indeed that is as indicated) in the codebase, and is nothing more than taking an uncalled-for personal swipe. But since you brought it up, there were no "unsystematic experiments". I've had a running app with 100% source code posted to this list, for everyone to see; I posted the steps I had taken, the tests I had run, the output I received, and what my understanding was of various aspects of FFmpeg function, and my reasoning as to what the problems might be. I've also been very appreciative of any feedback or discussion given. That said, bottom line -- the "theories" of those replying turned out to be wrong. If my question was so boneheaded and elementary -- why wasn't it obvious? The code has been sitting there for a month now, I've just done my level best to ask the questions I had. 

Look, as I've said previously when others wanted to turn a problem of 1s and 0s into a personal attack -- I'm not here to have adversarial communication, I'm here to solve a code problem for a client. And in the most diplomatic way possible, I've tried to communicate -- and I'll be a little bit more precise about it this time around -- FFmpeg might be the greatest set of tools ever created, but the API, documentation, and examples leave much ambiguity and many questions. It isn't a user's API -- it's like a tech book written for a reader that has the foreknowledge of the author. That isn't a knock, it is merely an observation, and one in the best interest of the improvement of FFmpeg, not a diss of anyone's girlfriend or turf. Forget my own personal opinion about it, just read the posts that roll in on the mailing list...I've been on the list now for over a year -- the same questions continually arise. Ever thought to ask why that is? 

It isn't anything to get your knickers in a twist about -- that's GOOD info -- that's info that helps show the way to where things might be improved, clarified. I personally thought that was the spirit and intention of open source software -- by virtue of community interaction, the tools and understanding of how to use them were improved. I thought leaving the solution to my problem up on Github for others might be a nice contribution for others who come after with a similar use-case. But it has become quite clear through having to see this problem through that the mere asking of questions has definite boundaries here, and there are those that take affront to a simple deductive process if there's any remote insinuation that there might be an issue (and I don't even mean a bug here, I mean a potential usage issue) with FFmpeg. Considering all possibilities until they are ruled out via testing -- don't know what to tell you. That's a common approach. No fingers pointed, no offense intended. Its all nuts and bolts. 

B