Hi,

as it seems, the mp3 plugin in
/usr/lib/kde4/libaudiocd_encoder_lame.so currently relies on the
existence of the lame frontend in /usr/bin/lame instead of using the
libmp3lame shared library which is available for ages. The problem
with this approach is that in order for this plugin to work, the lame
frontend must not be compiled with libsndfile support, c.f. [1] and [2].

However, losing libsndfile support for the frontend is a pity, since
it allows for a much wider range of input formats. So instead of
relying on a command line frontend in /usr/bin (and furthrmore relying
on specific compile time options for it to work properly), the mp3
plugin should e.g. dlopen() the libmp3lame library.

This way it will work when the library is installed and not if the
library is absent - just as it is now with the frontend, but without
the libsndfile compatiblity issue.

Cheers,
Fabian


[1] http://osdir.com/ml/kde-commits/2010-02/msg05221.html
[2] http://bugs.kde.org/show_bug.cgi?id=230026

BTW, the lame encoder plugin has been rewritten in May 2005.

SVN commit 417210 by bmeyer:

Completely new mp3 (lame) encoder that uses KProcess and outputs the
results to a temorary file so *finally* the Xing tag can be set.  This
is also the beginings of the new encoder(s) for audiocd which will
finally produce the merger of KAudioCreator and audiocd (and perhaps
Juk?).

BUG:79235


  M  +216 -527  encoderlame.cpp
  M  +36 -35    encoderlame.h

The background was that the lame_mp3_tags_fid() function of
libmp3lame, which appends a Xing VBR tag to the mp3 file, could not be
called, as thw target is not a regular file. I don't know if this
situation has changed fundamentally within the last five years, but
maybe it's worth at look at <http://bugs.kde.org/show_bug.cgi?id=79235>.

Cheers,
Fabian