search for: fatfing

>>> 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

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

On 05/12/2016 10:35 AM, Amit Ashara wrote: > For HMI panels, except for the capture pattern and a single page segment > entry, other fields are not important, and which results in almost 7% > overhead for a 20ms raw frame encoded with Opus. I'm not sure how you get a 7% overhead. In most uses I've seen, the overhead is more around 1%. > At the same time the > file

This is just a rediff and retest - no ext3 changes in this release. http://www.uow.edu.au/~andrewm/linux/ext3/ The latest diff is against linux-2.4.9. The version of ext3 in -ac kernels is current. -ac's ext3 has the "buffer tracing" debug code removed from the non-ext3 files, so the 2.4.9 diff is more useful for bug hunting. I should generate a diff against -ac to enable

Hello Jean-Marc, As an example, I am using the output of opus encoder to store the file as the following format and read back the same during decode process, without having much overhead. (Thought it would be useful to put a picture rather than running text) [image: Inline image 2] Regards Amit On Thu, May 12, 2016 at 10:47 AM, Amit Ashara <ashara.amit at gmail.com> wrote: > Hello

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) + 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

The format you're describing here actually has *more* overhead than Ogg, not less. It's also unseakable, not robust errors, and without support for metadata. I'm not sure why you would want that. It's not like you're forced to include much data in the Ogg metadata (which seems to be the source of all the overhead you're seeing). Jean-Marc On 05/12/2016 11:51 AM, Amit