[FFmpeg-devel] [PATCH] libmodplug wrapper

[Jai Menon]

On Sat, Jul 11, 2009 at 3:11 AM, Kostya<kostya.shishkov at gmail.com> wrote:
> On Sat, Jul 11, 2009 at 02:04:08AM +0200, Michael Niedermayer wrote:
>> On Fri, Jul 10, 2009 at 01:24:27PM +0000, Jai Menon wrote:
> [...]
>> > >
>> > > I wish i knew ...
>> > > my knowledge of these formats is shallow, if you have a link to some spec/doc
>> > > of some representative one so i can get a better feeling of what would be
>> > > needed for seeking that link would be appreciated ...
>> >
>> > Try ftp://de.hornet.org/pub/demos/code/audio/docs/fmoddoc.zip
>> > I wrote a protracker renderer in 16bit asm once based on that, and its
>> > pretty verbose.
>> >
>> > I'll again summarise the issues here :
>> >
>> > libmodplug requires the entire file to be buffered into memory so we
>> > have to read the entire contents of the file. If this was split into a
>> > decoder and demuxer, the demuxer would have to do this somehow, which
>> > i think would be ugly.
>> >
>> > Assuming we go that route, the next problem is adding seek support.
>> > Seeking through libmodplug is using the api call ModPlug_Seek and the
>> > demuxer will also need to link to libmodplug. This seems like a bad
>> > approach to me. After all, the primary reason for such factoring into
>> > demuxer and decoder (other than clarity) is to allow for separation
>> > between lavfo and lavc, isnt it? In this specific case, a user won't
>> > be able to do mod decoding in the absence of either lavfo or lavc.
>>
>> The primary reason for the seperation in this case is so we can watch
>> avi/mkv/nut files that have h264 video and mod/s3m/... audio
>
> Err, you can legally kill anybody trying to make such perverted format
> (i.e. Matroska devs).
>
> From my experience (several MOD-like and Adlib tracker formats in DOS
> times), you can represent tracker as two parts: samples and notes. For a
> bit modern people - like MIDI file with its own soundfont.

I guess you mean "General MIDI". The one which uses soundbanks etc.
Traditional MIDI is still important to modern folks because people
still implement those event driven synths, kinda inspired by old SMF
file format (events+timestamps). Doesnt require storing
samples/soundbanks and output signal has a very analog feel.

> So usually you have hundreds of kilobytes or more of samples (which may be treated
> as extradata) and less than 1KB of notes which define what to play.
> Also notes are grouped into patterns and subpatterns which may be
> repeated certain number of times, with speed changes that results in each
> part playing time very greatly varying. This makes it an awful sound format
> for generic container.

Definitely agree.


-- 
Regards,

Jai