[opus] Ogg Format

[Amit Ashara]

Hello Ulrich

20ms is the size of each frame. The overall sound clips may be 0.25 - 0.75
secs each.

Regards
Amit

On Fri, May 13, 2016 at 2:15 AM, Ulrich Windl <
Ulrich.Windl at rz.uni-regensburg.de> wrote:

> >>> Amit Ashara <ashara.amit at gmail.com> schrieb am 12.05.2016 um 17:47 in
> Nachricht
> <CAEyg9sgjbsxQY-=VnhQrKiGeTcFSRr1wxOPUhNyCQF8Piuahow at mail.gmail.com>:
> > Hello Jean-Marc,
> >
> > Assuming that a 48KHz, 20ms 8-bit linear PCM data which is 960 bytes is
> > compressed to 64 bytes (for assumption). The with the Oggs header (4
> byte)
>
> Actually what I don't understand ist this: If your whole audio is 20ms,
> why do you care at all to compress it?
> Is it that your audio is much longer, but you want to encode little chops
> of audio for some reason?
>
> > + 1 segment entry (which is the size of the segment itself) + 64 bytes
> will
> > amount to (4+1)/(4+1+64) = ~7.2%. This when compared with the original
> Oggs
> > container itself for the same data payload size (26+1)/(26+1+64) =
> ~29.6%.
> > Even if it takes a larger payload the Oggs container will still have a
> > larger overhead
> >
> > I also know using the segment table efficiently to hold 1 second of data
> > would reduce the overhead to 1-2%, but increases the processing time on
> > embedded systems.
> >
> > Also I should have been more clearer on stream.I meant an audio file. I
> > agree that Opus does not limit the user to use Oggs-Opus container, but
> > having a lite version of the same which can be simple for mid-low
> > microcontrollers would allow users to switch between the two formats
> > (Oggs-Opus or Lite) based on the device requirements/limitations while
> also
> > enabling conversion tools to be made available easily.
> >
> > I am with you on not creating a new container, but this is a suggestion
> > (microcontrollers benefit a lot with simpler file formats, e.g. lwIP,
> Tiny
> > FatFs)
> >
> > Regards
> > Amit
> [...]
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/opus/attachments/20160513/f2de3d05/attachment.html>