[FFmpeg-soc] [soc] libavsequencer [PATCH 02/08] Sub-song public API header file.

[Sebastian Vater]

Stefano Sabatini a écrit :
> I tend to agree with Vitor here.
>
> BSS = Big Sound Struct = Sound Module Descriptor
>
> This describes a sound module, so it should be as generic and abstract
> as possible, possibly it shouldn't contain format-specific
> information. This is very important if we want to keep a clean design.
>   

Yes, I agree on that!

> As for the compatibility problem, let's consider this scenario.  Anna
> is composing a module song. She's using a fancy editor which links
> against FFmpeg/libavsequencer, which works through saving a binary
> representation of the libavsequencer BSS.
>   

That's a point I was addressing also, how do we ensure we have always a
binary representation, right now, only IFF-TCM1 does that job (at least
with my current BSS).

> This representation is really generic, so it doesn't depend on the
> features of the format which will be used to store the song module.
>   

Please note that setting the S3M/etc. compatibility flags also don't
enforce you to store that in these formats, it just ensures that _IF_
you do it, it will playback for sure correct, nothing more or less.

You can still save such a file to a completely different format but
shouldn't wonder if there might be issues.

Anyway, if we want to remove them, we'll find an alternative to store
the information on how effects are handled. If we just move them, we
won't. So that's the next question to address?

> Now Anna wants to let his friend Bob hear the song module she's
> composing. She can save the song using one of the many sound module
> formats, S3M, XM/IT, TCM1. When she tries to save to S3M, her program
> may cry out that it isn't possible to save to that format, as that
> format doesn't allow to store some of the features of the composed
> song.
>   

Yes, but to _know_ that it can't be saved in S3M the global volume
command has e.g. to be set accordingly, if that's not the case there's
no chance to find that out.
Or do you simply mean renaming that field instead of S3M_COMPAT_FLAG to
sth. like GLOBAL_VOLUME_AFFECTS_AFTER_NEW_NOTE?

> Is that a problem? I don't think so, and indeed when using a word
> processor this happens all the times, when saving you can either do
> two choices:
>
> * lose the information stored in the binary representation. Which
>   information to lose and which to keep is a problem of the program
> or
> * store the information in a more expressive format
>
> For example if you save a word document to txt file, the program will
> discard some of the features of the document when performing the
> conversion.
>   

Yes, but unfortunately, the word processor does know that it can't be
saved, so we need to actually store this stuff somehow, right?

> >From the usability point of view, it is a problem of the interface
> (not of the internal representation of the information), to provide
> compatibility hints to the user. This can be implemented in various
> ways, for example Anna knows that his friend Bob only likes to hear
> S3M sound modules, so she may check a S3M compatibility flag in her
> fancy composer, so she'll be sure that the composer application *won't
> allow her* to add features which cannot be represented in a S3M file.
>   

A question here, is there any way in FFmpeg to get applications know
what module demuxers / muxers are registered? So they can query them for
the limit? This would solve the issue in a perfect way!

> libavsequencer may help the application providing such compatibility
> information in some table or providing an API for that, which should
> be anyway separated from the sound module representation aka BSS.
>   

As I already replied to Vitor, the limits.h idea is great! But give me
some time on this to really get clarified what and how put to limits.h
exactly and what not.

For the points I mentioned in song.h they're NOT hard limits, they're
even useful beyond tracker compatibility, because slides etc.
automatically stop at that value without adding a slide effect to each
row and see if it's beyond my wanted limit.

The user customizable limits allow me to copy the slide effect over the
whole effect to the whole track (i.e. all the rows) without worrying
anything about it, thus making life way easier. Without these, I would
have to add it row by row playback the row to check if it's beyond, or
add all and remove them row by row (if I use 256 rows per pattern, this
can be in worst case to 255 attempts).

Music composers with trackers often tend to work this way. Just that
they expect simply not exceeding the absolute min/max values, but there
are reasons I want a volume e.g. always range between 0x40 and 0xC0
instead of the default 0x00 and 0xFF.

-- 

Best regards,
                   :-) Basty/CDGS (-: