[FFmpeg-devel] GSoC mentor for audio module playback system requested
Sat Apr 17 19:35:11 CEST 2010
Jai Menon a ?crit :
> On Sat, Apr 17, 2010 at 7:50 PM, Sebastian Vater
> <cdgs.basty at googlemail.com> wrote:
> To clarify, I meant the _internal_ format we would use within ffmpeg.
> Module loaders imho cannot be represented within the existing
> demuxers+decoders framework. So we would (possibly) have loaders which
> fill an AVModule/AVPattern/whatever, defined functions which extract
> (and maybe unpack) pattern data and feed the renderer, manage
> instrument/sample data etc. And of course reusing code where
I understood this, the reason I posted the link to TuComposer specs is
that I have adressed the same problem with TuComposer (after all that
was the main reason why I invented TuComposer) and therefore the data
structures used in TuComposer could be a very good base for ffmpeg
internal format, too.
Since TuComposer itself is not an application but a shared/static
library, it's more a matter of transforming my data structures to
AVModule / AVPattern / etc. than rewriting my code.
This is even more true since both projects (TuComposer and ffmpeg) are
plain C although there is still some small left-over of m68k assembly
language stuff which has yet to be converted to C (this includes all
loaders except my own TCM format).
BTW: AVPattern is not a good way to do this, since there are trackers
out there which don't use a pattern scheme but a track scheme instead.
Also remember that some trackers also support sub-songs (even plain MOD
has an undocumented feature for this by using position jump commands).
The main difference is that each track can run at different speed. There
are some old Amiga module formats (notably FutureComposer) which use
such features. And I guess that there also some PC trackers which have
such a feature.
Most trackers, however, use an order list and map a single pattern to
Track based differs in that each order maps a track to a single channel
in the order list.
TuComposer even has a complete synth sound assembler which is comparable
to normal processor assembly language so if there is some strange format
which can't be represented yet, this can be "emulated" by the synth
My internal format in TuComposer is already flexible enough to play all
MODs/S3Ms/XMs/ITs and FutureComposer modules I have on harddisc (which
is more over 1k) perfectly (at least I'm not able to hear any audible
difference to their respective original trackers), since it was designed
for extensibility from the very beginning.
My playback engine and my loaders also handle (hopefully all?)
undocumented features of the trackers the formats are originating from
(which were BTW a hell to figure out).
Just download the source and look at the includes...
Also read my idea about the OptiMOD module format which is specially
designed for pure players which require performance (it's mainly a
preprocessed module for the mixing engine).
Hope this helps a bit!
> I don't remember anything in particular which required RE, but I might
> be forgetting something..
Just was doing a quick look to find that RE stuff again but wasn't
successful, it was probably somewhere in the documentation of the
samples you've been providing at the IFF-ANIM page...will take a deep
:-) Basty/CDGS (-:
More information about the ffmpeg-devel