Re: [ecasound] broken lame/mp3 output

Hi,

On Fri, 20 Mar 2009, Kai Vehmanen wrote:

> How to fix the defaults (without breaking support for some version(s) of
> lame), now that's a harder nut to crack. The good news is the lame now has

oh boy, this turned out to be quite painful. Until now (2.6.0), ecasound
has written little-endian samples to lame, and used lame's "-x" option to
swap the samples (i.e. lame-3.96 by default expected to get big-endian
samples, even when running on little-endian machines). In
lame-3.97, things are yet more confusing as with "-x" it expects
little-endian samples, and with no "-x", native-endian (so in many cases,
like on x86, it doesn't matter if you pass -x or not). But already with
3.97, runnnig ecasound+lame3.97 on a big-endian system (PowerPC for
instance), would not work anymore (you get static as output).

Lame-3.97 also added "--little-endian" and "--big-endian" options, but
unfornately these don't really work as you might expect (only affect
lame's use of libsndfile).

Not to make life too easy, the same options "--little-endian" and
"--big-endian" are fixed in 3.98 and now also impact the samples read from
standard input. But from ecasound's point of view, 3.96, 3.97 and 3.98
have all distinctly different interfaces. :P

Up until 3.97 things still worked with ecasound on little-endian systems,
but 3.98 had one more change: unless '-r' was passed, lame would insist on
performing seeks on the input data. This would of course fail with
ecasound (as up until 2.60, ecasound did not by default pass '-r'). This
broken ecasound+lame on all machines.

Then another angle to the problem is that when you upgrade ecasound, the
user preferences in ~/ecasound/ecasoundrc are not automatically updated.
This makes sense of course, but also means that if I change the default
output endianess for mp3 encoding, upgrade of ecasound would break mp3
encoding for all people who customized the encoding params in their
ecasoundrc. So this is not really a realistic option.

Ugh, what a mess!

Fortunately with sufficient hacking and degree of code-ugliness, you can
solve any sw problem. ;) I just committed a patch to the git repo that
tries to solve the problem in majority of the possible cases. I've tested
the patch with all lame versions 3.96-3.98.2 [1], and also tested with a
legacy ecasoundrc. After some finetuning, now all combinations except
'ecasound <=2.60' and 'lame >=3.98' work. I think this is the best
compromise. Let me know if there is still some combination that causes
problems.

[1] lame 3.96 was released in April 2004, so we are talking about
     fairly old releases. I did test the git version of ecasound with
     lame 3.89 (from 2001), and that works as well, so I think we
     have sufficient coverage now. ;)

PS And in all cases, all known possible problems can be fixed by editing
    your ~/.ecasound/ecasoundrc so this mail is about the out-of-the-box
    experience...

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sun Mar 22 04:15:01 2009