New library and aRts-plugin

[Allan Sandfeld Jensen]

On Sunday 30 May 2004 14:29, Neil Stevens wrote:
> On Sunday May 30, 2004 5:28 am, Stefan Gehn wrote:
> > Am Sonntag, 30. Mai 2004 14:14 schrieb Allan Sandfeld Jensen:
> > > After having hinted it in a bug-report that I am working on replacing
> > > mpeglib, I better introduce it properly on kde-multimedia and ask for
> > > permission to add it to the feature-list.
> > >
> > > The project name is currently akodelib and will be imported to
> > > kdenonbeta in a weeks time or so.
> > > [...]
> > > Since feature-plan freeze is two days away, I plan to commit the
> > > attached patch to the feature-plan tomorrow, unless anyone has serious
> > > objections about the library's inclusion in kde-multimedia.
> >
> > I don't think it's a good idea to cram in a mpeglib replacement shortly
> > before a release. Also what about video playback? Not everbody has/wants
> > xine. Actually I don't even see a need to replace mpeglib, it works
> > quite well. All the problems I have come from arts and its limited api
> > (I want to gather more info about the currently played data,
> > unfortunately playobject don't allow much in that area).
>
> Also, over the last few years a lot of work has gone into trying to make
> mpeglib work portably.  Mpeglib shouldn't be removed until its replacement
> is proven on many platforms.

I agree. I didnt expect to remove mpeglib for KDE 3.3, only to obsolete it ;) 
Note however that my "library" does not do any decoding or encoding itself 
like mpeglib does (actually it has an old fork of splay), it used the 
official decoders for flac and vorbis, and MAD for mp3. It is really nothing 
more than a wrapper of various APIs with some resampling, pthreads and 
buffering.

mpeglib has several problems, there is the really old one with not playing the 
last few seconds of every song. Then there are several reports of problems 
with non-44100 frequency samples. And lately a (now fixed) optimization 
problem in the ancient and unmaintained splay-decoder source. And if you look 
at http://www.underbit.com/resources/mpeg/audio/compliance/ you will see that 
splay is nowhere near the complience/accuracy of MAD.


`Allan