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.<div>
<br></div><div>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.</div>
<div><br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 8:28 PM, Benjamin Schwartz <span dir="ltr"><<a href="mailto:benjamin.m.schwartz@gmail.com" target="_blank">benjamin.m.schwartz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br>
<br>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.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jan 16, 2013 at 11:55 AM, Corey Shay <span dir="ltr"><<a href="mailto:cshay892@gmail.com" target="_blank">cshay892@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">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.<div>
<div><br><br><div class="gmail_quote">
On Wed, Jan 16, 2013 at 11:50 AM, Gregory Maxwell <span dir="ltr"><<a href="mailto:gmaxwell@gmail.com" target="_blank">gmaxwell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Jan 16, 2013 at 2:45 PM, Corey Shay <<a href="mailto:cshay892@gmail.com" target="_blank">cshay892@gmail.com</a>> wrote:<br>
> Why use Opus for this? Video games, of course. Memory<br>
> constraints.<br>
<br>
</div>If you use Opus or any other lossy encoder for this you will violate<br>
their perceptual assumptions and get results that sound like crud. A<br>
lossy codec (or encoder) could— in theory— be design to work more<br>
sanely in this use case, but not for the Opus format (because much of<br>
the encoder's behavior is baked into the format for efficiency<br>
reasons) and not without substantially compromising the effectiveness<br>
of the lossy compression.<br>
</blockquote></div><br>
</div></div><br></div></div>_______________________________________________<br>
opus mailing list<br>
<a href="mailto:opus@xiph.org" target="_blank">opus@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/opus" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>