<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<br></div>Amit<br></div><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">ashara.amit@gmail.com</a>> schrieb am 12.05.2016 um 17:47 in Nachricht<br>
<CAEyg9sgjbsxQY-=<a href="mailto:VnhQrKiGeTcFSRr1wxOPUhNyCQF8Piuahow@mail.gmail.com">VnhQrKiGeTcFSRr1wxOPUhNyCQF8Piuahow@mail.gmail.com</a>>:<br>
<span class="">> 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 class=""><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>