[Clam-devel] Ogg seeking
David García Garzón
dgarcia at iua.upf.edu
Wed Jun 3 13:38:20 PDT 2009
I was unsure of either option. I am still unsure. In summary, I am just
refactoring both until they blend.
On one side sndfile has already seek, float wavs, lockfree support and nicer
interface for multichannel than MultiChannelAudioFile* but, on the other hand
it still lacks ogg, mp3, error condition safety, and, important, unit tests
to evolve it without regressions. On the other hand, audiofileio already
implements sndfile, ogg and mp3 support, is test backed and the error
conditions are properly handled (and tested).
I aggree that complexity of sndfile plugin code was still not that high than
audiofileio but, believe me it had already a very high complexity/feature
ratio. Adding features required refactoring and so i did. Now i think that
the new features are completely clear and abstracted out as helper classes
but the codec itself. To see how to abstract the codec i took a look to the
audiofileio stack. But i applied the understand by refactor principle ;-) and
soon i had a higher level interface was not that far of what we where leading
sndfile to. Being backed by tests was nice in this case.
Being both interfaces that similar, moving features from one to another seems
easy so we have many options now. Adding seek was a couple of lines for each
codec (not with mp3 but that's a mad problem, not audiofilein). It is not a
double effort, being able to address codec complexity and lockfree complexity
in separate code bases has been very insightful to me.
BTW, i just added a very preliminar seek for mp3. A better solution is needed
as currently we are navigating along the mp3 sequencially and just forward so
it is too expensive, meaning being stopped by jack depending on which jumps
you do. In Miguel's code differentiates constant rate, variable rate with
xing header (which i think acts like an index) and and
not-indexed-variable-rate. In the later case we should build the index
Let's talk about it tomorrow. Maybe we have some spare time then.
On Wednesday 03 June 2009 07:48:30 Pau Arumí Albó wrote:
> David, are you sure that refactoring and enriching
> Mono/MultiChannelFilePlayer is worth the efford, compared to keep
> SndfilePlayer evolving (and changing its name)?
> The latest was ment to be a replacement using a much simpler approach.
> Anyway, lets talk about it at the office.
> El dt 02 de 06 de 2009 a les 15:11 +0200, en/na David García Garzón va
> > At last, so many refactorings lead to features.
> > * MonoAudioFileReader seek control that seeks on PCMs and OGGs, not in
> > MP3 yet * MonoAudioFileReader has time, frame and progress controls (all
> > formats)
> > The idea is merging most of the SndFile stuff. Look free disk access will
> > force to evolve even more the AudioCodec::Stream interface which is
> > perfect.
> > Regarding MultiChannelAudioFileReader, i really learned to hate the
> > channel selection complexity which i guess nobody uses but the tests and
> > few examples. It has no sense at all selecting the channels you want to
> > write on a multichannel file. And if you are reading just ignore the
> > ports. I propose to implement the channel policy of the one
> > SndFilePlayer/Writer. I would also suggest to name it
> > AudioFileReader/Writer, that is, removing the 'MultiChannel' prefix.
> > So the related TODO's on the stack are:
> > - Integrate LockFree features (almost extracted as classes already)
> > - MP3 seek (i guess that codec's lenght computation has some hints)
> > - Being able to write Float wavs (means racionalizying format selection
> > as in SndFileWriter).
> > - Refactor the codecs
> > - SampleRate adaptation
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
More information about the clam-devel