similar to: Stop opusenc from generating any comments?

>>> Terence Eden <terence.eden at gmail.com> schrieb am 19.04.2020 um 12:48 in Nachricht <12670_1592540909_5EEC3EEC_12670_238_1_CABV2FHjaGEd4u4r7BfHaAyj=P1wP_8z7u7pWuMHy hV6XqSXVA at mail.gmail.com>: > The opusenc tool automatically adds metadata - even if you don't specify > any. > For example, these tags are created by default on my files: > ENCODER=opusenc

Hello Jean-Marc, So for the moment we can assume that this method is also OK to use? 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? Regards Amit On Wed, May 11, 2016 at 12:09

(Please wrap your lines.) On Oct 26 01:38:34, Ulrich.Windl at rz.uni-regensburg.de wrote: > Playing with Opus 1.3 I converted a tone sweep with a sample rate of 96kHz (just for fun). Before I had converted that from WAV to FLAC, and to Vorbis without problems. Can you please post the original wav? I am not sure what Audacity means by a logarithmisch sweep. Is that a fixed number of Hertz per

Hi Amit, I'm not sure what you're trying to ask, but the reserved space in the header is an optional thing. Encoders are free to do it, but are not required to do so. Jean-Marc On 05/11/2016 01:32 PM, Amit Ashara wrote: > Hello Jean-Marc, > > So for the moment we can assume that this method is also OK to use? > > On Embedded Systems, both SRAM and Flash can be a

Hi, I am interested in this part of the answer: "Make sure both are also linked to the same libopus (opusenc could be using the system libopus 1.0.x while opus_demo is from git)" I dowloaded a tarball distrib of libopus (1.1-beta),build and installed it,and afterwards did the same with opus-tools (0.1.7),using the former installed libopus library (also using libogg 1.3.1). When I execute

Hello Ralph I ran the opusenc.exe on a wave file and checked the OpusTag section. My concern is on Total Segment Size being >> than the actual data being put. Is this just an example of implementation or does a size of 764 BYTES kept as a place holder for putting more data? 4f 67 67 53 = Oggs 00 = Version 00 = Header 00 00 00 00 00 00 00 00 = Granule Position a5 73 00 00 = Bit Stream

On 05/11/2016 12:35 PM, Amit Ashara wrote: > I ran the opusenc.exe on a wave file and checked the OpusTag section. My > concern is on Total Segment Size being >> than the actual data being > put. Is this just an example of implementation or does a size of 764 > BYTES kept as a place holder for putting more data? Yes, opusenc does reserve some space in the header so that tags can

I suspect the main difference is due to time alignment of the samples and the exact trimming at the beginning and at the end of the encoded files. I also note that there's a missing "--" in front of "bitrate" and only one "-" instead of two for cvbr in your opusenc command line. Make sure both are also linked to the same libopus (opusenc could be using the system

Hello Ulrich, Putting some extra space is the not the reason for this request. It is the overhead of the frame v/s payload size. Basically larger the payload less % the overhead is (and that makes sense). However the complexity of implementing a read file structure where the file pointer has to go back-forth for reading the payload when multiple segments have to be read, CRC32 (something which

opusdec -V opusdec opus-tools f2a2e88 (using libopus unknown) I've got an opus file encoded from a .wav off a cd, 44100Hz: opusinfo 2-24-Overture_in_C_\(In_Memoriam\).opus Processing file "2-24-Overture_in_C_(In_Memoriam).opus"... New logical stream (#1, serial: 38134f1f): type opus Encoded with libopus unknown User comments section follows... ENCODER=opusenc from opus-tools

Are there comparable presets or recommendations for opusenc vbr parameters? lame --preset standard --> opusenc ??? lame --preset extreme --> opusenc ??? I have used opusenc without custom vbr parameters and the files were much smaller than for lame's standard preset but I can't answer if that's comparable or the result was lossier in opus. Hearing tests of course show no

Hi, I think I might have kind of, sort of found a bug in opusenc. But do correct me if I am worng. :) When converting an FLAC file that contains RG tags written by bs1770gain the resulting opus file has a way, way too high RG value. I am talking >90dB(!). Here is the metaflac output of the flac file: % metaflac --block-number=2 --list bs.1770/test.flac METADATA block #2 type: 4

On Sun, Dec 15, 2013 at 9:42 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: > Are there comparable presets or recommendations for opusenc > vbr parameters? > > lame --preset standard --> opusenc ??? > lame --preset extreme --> opusenc ??? > > I have used opusenc without custom vbr parameters and > the files were much smaller than for lame's

Hi, I have found differences in quality between opus_demo and opusenc/opusdec. I used for both applications the same raw pcm file,16 bit,48khz,litle endian. i use libopus 1.1-beta and opus-tools-0.1.7. The command for opus_demo is: opus_demo audio 48000 1 64000 -cvbr -framesize 10 in.pcm out.pcm For opusenc/dec: opusenc --raw --raw-chan 1 bitrate 64 -cvbr --framesize 10 in.pcm in.opus

On 15 November 2013 18:27, John Buckman <john at magnatune.com> wrote: (sigh, once more I accidentally replied off-list...) > The docs for opusenc at > https://mf4.xiph.org/jenkins/view/opus/job/opus-tools/ws/man/opusenc.html > > don't mention any way to specify the track number metadata. > > Is there an undocumented way to do this, or this feature not available? >

Le 19-12-18 à 12 h 29, Marc Lavallée a écrit : > Hi Andrew, > > I suspect that the configure option should be enable-ambisonics > (instead of enable_ambisonics), but for each of opus, libopusenc, > opusfile and opus-tools git repos (on master branch), when I try > "./configure --enable-ambisonics", I get this error message: > > configure: WARNING: unrecognized

>>> Amit Ashara <ashara.amit at gmail.com> schrieb am 11.05.2016 um 19:32 in Nachricht <CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com>: > Hello Jean-Marc, > > So for the moment we can assume that this method is also OK to use? > > On Embedded Systems, both SRAM and Flash can be a restricting factor > besides the compute time. To

>>> Jan Stary <hans at stare.cz> schrieb am 05.11.2018 um 11:05 in Nachricht <20181105100534.GB44329 at www.stare.cz>: > (Are we off‑list now by intention?) No, just fooled by the list defaults (some need just reply, others need reply to all) > >> Did you also try to listen at the beginning, shortly before the real tone > appears in the audible spectrum?

Hello All, This is my first appearance to the opus mailing list. My name is Michael Mehari and i am a researcher at Ghent University mainly on cognitive radio networking. Recently i am working on a demo scenario on self adjustable wireless audio conferencing and i selected opus for the audio encoding and decoding part. specifically the applications (i.e opusenc and opusdec) from opus-tools

Hello! I encoded a voice file (48kHz) with opusbin\opusenc.exe with the standard settings and decoded it. The output was amazing. I could not hear any loss at all. Then i encoded the same file with opus_demo.exe and standard settings and then decoded it. The output had a sizzling noise, even when I used full bandwidth. I think I have played around with any of the settings in opus_demo.exe,