[ogg-dev] can you suggest on extending ogg as short-clip container and the make of its tool?

[Conrad Parker]

On 6 March 2013 18:26,  <gildororonar at mail-on.us> wrote:
>
> Quoting "Benjamin Schwartz" <ben at bemasc.net>:
>>
>> I'm not sure how you reached this conclusion, but I think you should
>> revisit it.  I think everyone, including you, will be a lot happier if you
>> store each sound effect clip in its own file.  This is a common practice
>> for sound effects and samples in ogg.
>
> No it is not a common practise. In fact I fail to find a single
> computer game using separate file for each context / sound effect
> short clips.
>
> I will start naming a few that I studied in the last a few days.
> Samurai Sprit PC edition, Fallout 3 and Skyrim, L.A. Norie. Most
> common practise is to enclose them in something indexable. For
> example, lots of Bethesda games uses an container format (seems
> non-compressing) they invented themselves, called ".bsa". I'd like to
> say using each game vendor's own archive format is more likely the
> standard practise.
>
> There are a few strong reasons to do it: the clips are often as short
> as 4kB, in a 64kB cluster file system it is a waste of more than 90%
> space. If they are installed on FAT32 the FS chokes more.

I agree with you that it is practical to archive many sound effect
files into an indexable container, and
I've also heard that this is common in the game industry.

I agree with Ben that a file containing a single Ogg bitstream is a
poor choice of container for that use case.

My understanding is that it is common to have the data for each sound
effect in a standalone Ogg bitstream,
and to pack these Ogg bitstreams into a single file in a different
container which has been designed for
random access.

This index could be as simple as concatenating the sound effect files
and providing a separate
index file mapping filename to (start byteoffset, length in bytes). I
can't see any advantage to
modifying the encoder to use larger Ogg pages, and anything involving
bisection search to find the
data is unnecessarily slower and more complex than just providing an
index of byte offsets.

Conrad.