<div dir="ltr"><div><div>Hello Jean-Marc,<br><br></div><div>So for the moment we can assume that this method is also OK to use?<br><br></div><div>On Embedded Systems, both SRAM and Flash can be a restricting factor besides the compute time. To optimize the utilization of embedded resources, may I suggest a simplification of the Ogg-Opus format and can this be considered by the Opus org and IETF as an addition?<br></div><div><br></div>Regards<br></div>Amit<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 12:09 PM, Jean-Marc Valin <span dir="ltr"><<a href="mailto:jmvalin@jmvalin.ca" target="_blank">jmvalin@jmvalin.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/11/2016 12:35 PM, Amit Ashara wrote:<br>
> I ran the opusenc.exe on a wave file and checked the OpusTag section. My<br>
> concern is on Total Segment Size being >> than the actual data being<br>
> put. Is this just an example of implementation or does a size of 764<br>
> BYTES kept as a place holder for putting more data?<br>
<br>
</span>Yes, opusenc does reserve some space in the header so that tags can<br>
later be modified "in place", without having to rewrite the entire file.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jean-Marc<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> 4f 67 67 53 = Oggs<br>
> 00 = Version<br>
> 00 = Header<br>
> 00 00 00 00 00 00 00 00 = Granule Position<br>
> a5 73 00 00 = Bit Stream Serial Number<br>
> 01 00 00 00 = Page Sequence Numner<br>
> 90 a9 36 42 = Checksum<br>
> 03 = Page Segments<br>
> ff ff fe = Each Segment Size (TOTAL SIZE IS 764 BYTES)<br>
> 4f 70 75 73 54 61 67 73 = OpusTags<br>
> 0b 00 00 00 = Vendor String Length of 11<br>
> 6c 69 62 6f 70 75 73 20 31 2e 31 = "libopus 1.1"<br>
> 03 00 00 00 = User Comment List Length of 3<br>
> 25 00 00 00 = User Comment #0 String Length of 37<br>
> 45 4e 43 4f 44 45 52 3d 6f 70 75 73 65 6e 63 20 66 72 6f 6d 20 6f 70 75<br>
> 73 2d 74 6f 6f 6c 73 20 30 2e 31 2e 39 = "ENCODER=opusenc from<br>
> opus-tools 0.1.9"<br>
> 0a 00 00 00 = User Comment #1 String Length of 10<br>
> 74 69 74 6c 65 3d 48 4f 4c 41 = "title=HOLA"<br>
> 1e 00 00 00 = User Comment #2 String Length of 30<br>
> 45 4e 43 4f 44 45 52 5f 4f 50 54 49 4f 4e 53 3d 2d 2d 6d 61 78 2d 64 65<br>
> 6c 61 79 20 32 30 = "ENCODER_OPTIONS=--max-delay 20"<br>
> 00 00 00... ALL THE WAY TO THE NEXT Oggs Container<br>
><br>
> Regards<br>
> Amit<br>
><br>
> On Tue, May 10, 2016 at 10:47 PM, Ralph Giles <<a href="mailto:giles@thaumas.net">giles@thaumas.net</a><br>
</div></div><span class="im HOEnZb">> <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a>>> wrote:<br>
><br>
> On 10/05/16 02:37 PM, Amit Ashara wrote:<br>
><br>
> > Is there a format document on the OpusTag structure? Search always shows<br>
> > up Vorbis but not Opus.<br>
><br>
> The basic format is shared with Vorbis, but the 'magic signature' is<br>
> different ('OpusTags' instead of '0x05vorbis') and vorbis puts a 0x01<br>
> value in an extra byte after the last tag.<br>
><br>
> The OpusTag packet layout is described in<br>
> <a href="https://tools.ietf.org/html/rfc7845.html#section-5.2" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc7845.html#section-5.2</a><br>
><br>
> Common tag names used for interoperability are described in the Vorbis<br>
> documentation. See <a href="https://www.xiph.org/vorbis/doc/v-comment.html" rel="noreferrer" target="_blank">https://www.xiph.org/vorbis/doc/v-comment.html</a><br>
> There are more extensive tag lists on some other sites.<br>
><br>
><br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> opus mailing list<br>
> <a href="mailto:opus@xiph.org">opus@xiph.org</a><br>
> <a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a><br>
><br>
</div></div></blockquote></div><br></div>