>>> 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[...]
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>
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>