[Libav-user] Audio quality loss while encoding

[Kalileo]

On May 1, 2013, at 07:14 , Brad O'Hearne wrote:

> 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. 

'presumably' - again you assume, and use such an assumption as the basis of a theory / recommendation.

Then, Paul did not recommend to remove it, but _you_ did.

>> , 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 offe
> nse intended. Its all nuts and bolts. 


This is another example of what I mean, you could have said that with 10% of the words you used. These long elaborations make it very difficult to understand your problem(s) and to help you (which I have tried several times, and which at least in one case have helped you to make progress).

So far, from what I remember, despite all the theories about mysterious problems in ffmpeg the solution to the problems you reported and elaborated here have not resulted in any bug report for ffmpeg. The solution was always that the assumptions you made, and based your elaborations on, were wrong. 

Others called that FUD, I call it half-theories.

My only point is (as said before) is that I recommend that, instead of developing theories about problems in ffmpeg based on assumptions, to check and recheck your assumptions, systematically, all of them. So far, once you started to do that, you found a solution to all problems you reported here, didn't you?

So this is merely an attempt to help you to get to a solution to your problems faster. Feel free to ignore it.

Over and out.