[opus] Ogg Format

Amit Ashara
Sat, 14 May 2016 17:30:17 -0000

Hello Jean-Marc

An update. Adding a basic ogg-opus container deocder added 1K extra code
for the following processing

1. Check Magic packet parser for OggS, OpusHead, OpusTags
2. Check for channel Family mapping to be mono
3. Extracting original sample rate, total size of audio stream
4. Checking for BOS, Continuation and EOS

No check or extraction of CRC, Sequence Number, contents of OpusTags and
remainder of OpusHead has been attempted.

Regards
Amit

On Fri, May 13, 2016 at 6:58 AM, Amit Ashara <ashara.amit at gmail.com>
wrote:

> 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/20160514/a7c1ec72/attachment.html>