[opus] Encoding ultrasonics

[Corey Shay]

Well, with game coding, you're always CPU constrained, and always memory
bound. Any cycles or bits you use in one place have to be taken from
something else. I've always liked Vorbis other than the fact that it has no
memory constraints and can grow unexpectedly. I've been inclined to modify
it heavily so that any Vorbis stream when opened can have a known fixed
cost that won't grow. Opus appeals to me because the memory cost is always
fixed, and better still, the whole initialized encoder or decoder can be
copied pointer free, which makes it an ideal choice for Cell processors.
Though, unfortunately it is quite slow at the moment.

Splitting the audio assets into 2 different versions has an obvious memory
issue, and also it won't work for dynamic real time pitching, like in the
case of a vehicle engine, or an effect where time slows down.


On Wed, Jan 16, 2013 at 8:28 PM, Benjamin Schwartz <
benjamin.m.schwartz at gmail.com> wrote:

> Opus shouldn't be particularly worse than Vorbis for this application ...
> but it also probably won't be any better, and it will take more CPU power
> to decode.  Vorbis is still a fine choice.
>
> If you are CPU-constrained, you might consider encoding more than one
> version of the audio at different base speeds, so that when playing at full
> speed or faster, you don't have to burn twice the CPU on decoding.
>
>
> On Wed, Jan 16, 2013 at 11:55 AM, Corey Shay <cshay892 at gmail.com> wrote:
>
>> Well, Vorbis doesn't sound too terrible when pitched down, though,
>> admittedly we haven't tried it with rates over 48k. It sounds close enough
>> to the original when pitched down to pass just fine.
>>
>>
>> On Wed, Jan 16, 2013 at 11:50 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
>>
>>> On Wed, Jan 16, 2013 at 2:45 PM, Corey Shay <cshay892 at gmail.com> wrote:
>>> > Why use Opus for this? Video games, of course. Memory
>>> > constraints.
>>>
>>> If you use Opus or any other lossy encoder for this you will violate
>>> their perceptual assumptions and get results that sound like crud. A
>>> lossy codec (or encoder) could— in theory— be design to work more
>>> sanely in this use case, but not for the Opus format (because much of
>>> the encoder's behavior is baked into the format for efficiency
>>> reasons) and not without substantially compromising the effectiveness
>>> of the lossy compression.
>>>
>>
>>
>> _______________________________________________
>> opus mailing list
>> opus at xiph.org
>> http://lists.xiph.org/mailman/listinfo/opus
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20130117/033e1e44/attachment.htm