<div dir="ltr"><div><div><div><div><div><div>Hello Jean-Marc<br><br></div>An update. Adding a basic ogg-opus container deocder added 1K extra code for the following processing<br><br></div>1. Check Magic packet parser for OggS, OpusHead, OpusTags<br></div>2. Check for channel Family mapping to be mono<br>3. Extracting original sample rate, total size of audio stream<br></div>4. Checking for BOS, Continuation and EOS<br><br></div><div>No check or extraction of CRC, Sequence Number, contents of OpusTags and remainder of OpusHead has been attempted.<br></div><div><br></div>Regards<br></div>Amit<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 13, 2016 at 6:58 AM, Amit Ashara <span dir="ltr"><<a href="mailto:ashara.amit@gmail.com" target="_blank">ashara.amit@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><div><div>Hello Ulrich<br><br></div>20ms is the size of each frame. The overall sound clips may be 0.25 - 0.75 secs each.<br></div><div><br></div>Regards<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">Amit<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 13, 2016 at 2:15 AM, Ulrich Windl <span dir="ltr"><<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank">Ulrich.Windl@rz.uni-regensburg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>>> Amit Ashara <<a href="mailto:ashara.amit@gmail.com" target="_blank">ashara.amit@gmail.com</a>> schrieb am 12.05.2016 um 17:47 in Nachricht<br>
<CAEyg9sgjbsxQY-=<a href="mailto:VnhQrKiGeTcFSRr1wxOPUhNyCQF8Piuahow@mail.gmail.com" target="_blank">VnhQrKiGeTcFSRr1wxOPUhNyCQF8Piuahow@mail.gmail.com</a>>:<br>
<span>> Hello Jean-Marc,<br>
><br>
> Assuming that a 48KHz, 20ms 8-bit linear PCM data which is 960 bytes is<br>
> compressed to 64 bytes (for assumption). The with the Oggs header (4 byte)<br>
<br>
</span>Actually what I don't understand ist this: If your whole audio is 20ms, why do you care at all to compress it?<br>
Is it that your audio is much longer, but you want to encode little chops of audio for some reason?<br>
<span><br>
> + 1 segment entry (which is the size of the segment itself) + 64 bytes will<br>
> amount to (4+1)/(4+1+64) = ~7.2%. This when compared with the original Oggs<br>
> container itself for the same data payload size (26+1)/(26+1+64) = ~29.6%.<br>
> Even if it takes a larger payload the Oggs container will still have a<br>
> larger overhead<br>
><br>
> I also know using the segment table efficiently to hold 1 second of data<br>
> would reduce the overhead to 1-2%, but increases the processing time on<br>
> embedded systems.<br>
><br>
> Also I should have been more clearer on stream.I meant an audio file. I<br>
> agree that Opus does not limit the user to use Oggs-Opus container, but<br>
> having a lite version of the same which can be simple for mid-low<br>
> microcontrollers would allow users to switch between the two formats<br>
> (Oggs-Opus or Lite) based on the device requirements/limitations while also<br>
> enabling conversion tools to be made available easily.<br>
><br>
> I am with you on not creating a new container, but this is a suggestion<br>
> (microcontrollers benefit a lot with simpler file formats, e.g. lwIP, Tiny<br>
> FatFs)<br>
><br>
> Regards<br>
> Amit<br>
</span>[...]<br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>