similar to: Q: "MP3 direct cut" for Vorbis?

Hi, I'm wondering: If you have audio files like foo1.ogg and foo1.mp3, and the Vorbis file has nice comments (title, tracknumber, artist, album, date, etc), is there a tool to copy the information to an MP3 file on a "best effort" strategy? I know that MP3 TAGs are quite limited regarding lengths. Regards, Ulrich

Hi! Sorry, I know the rules for comparing objective subjective listening impressions, but I'd like to know whether from the algorithmic or implementer's point of view the following personal impressions can be confirmed: Comparing MP3 with Vorbis at rather high bitrates, I had the impression the Vorbis sounded more crispy, while MP3 sounded somewhat softened. I preferred Vorbis for that

Hi, this is a bit off-topic, but maybe you can help me: When extracting the autio track of a concert on video DVD, I noticed that the *.VOB files each contained only about 16 minutes of music, resulting in multiple files. I extracted to flac for further processing, but now I wonder how to make one continuous sound stream of those: Can I simple concatenate the flac files to make on big file

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

Hi, I'm using a Samsung YEPP 6 for some time, but I recently got surprised: It seems that listening to Ogg (=Vorbis) empties the batteries much faster than listening to MP3. Both files have about the same bit rate. I did not make electrical measurements, but I think things are as they seem to be. Did anybody make similar experience? Or maybe "required CPU cycles to decode"

>>> Ralph Giles <giles at thaumas.net> schrieb am 21.12.2015 um 19:51 in Nachricht <CAEW_RkshUM55uwdvU6DsE17pLZki651Xvvu7d2Y6jObePXZwCQ at mail.gmail.com>: > On 21 December 2015 at 04:31, Ulrich Windl > <Ulrich.Windl at rz.uni-regensburg.de> wrote: > >> opusenc does not display the file name it processes. In Lunux when you use > some batch processing,

Hi! Useful advice, thanks! Actually I had been using foobar2000 to recode, because it just makes it so easy to convert multiple files while keeping the metadata (I confess, I'm a "tagger"). But it's easy to miss some encoder option when being presented some default suggestions in a dialog form... Apart form that I always had the impression that Opus could be quite smart

The overhead of Ogg (in file size) is pretty small and it's efficient enough for most applications (and uses far less CPU than the codec anyway). If anything, you might want to look at optimizing the existing Ogg implementation (e.g. like Tremor did in the context of Vorbis). Of course, you're always free to design a new container, but I doubt it's worth it and it's a lot of work

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

Hello, with OpenSSH_2.3.0p1 running in HP-UX 11.00 I noticed that the "SD commands" (like "swcopy") produce the following error when being logged in via SSH: ERROR: RPC exception: "Who are you failed (dce / rpc)" 11/29/00 11:20:18 MET Ideas? Regards, Ulrich P.S. Not subscribed to the list

Hi! I was just trying libopus0-1.1-3.2.x86_64 and opus-tools-0.1.9-3.2.x86_64 on openSUSE Leap, and I was wondering: opusenc does not display the file name it processes. In Lunux when you use some batch processing, it might be interesting! Example output for "for f in *.wav;do opusenc --bitrate 160 $f ${f%.wav}.opus; done": ---just on file--- Encoding using libopus 1.1 (audio)

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

Hi! You probably know already, but recently there's "fobbar2000 mobile" available for Android (I think Windows and iOS, too), and it plays Opus even ol older Android (like 4.0). Ulrich

Hi Ulrich, As Jean-mark recommended, we created "--enable-check-asm" config option to active OPUS_CHECK_ASM macros in the optimization, where the C function is called inside and the results of C and optimization functions are compared when encoding/decoding the real audio files. Thanks, Linfeng On Wed, Apr 19, 2017 at 11:46 PM, Ulrich Windl < Ulrich.Windl at

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

>>> Drew Allen <bitllama at google.com> schrieb am 10.10.2017 um 20:29 in Nachricht <CABQ9DctQ0+gBgUif7BBJpjjKR7_V_H5OC1JM47w50oaaLXL4Tg at mail.gmail.com>: > Hi Jean-Marc, > > Thanks for the feedback. Attached are my comments and an updated patch. > > 1) I see that it's adding an #include of stdarg.h to opus_multistream.h > Is that left over from the

>>> Linfeng Zhang <linfengz at google.com> schrieb am 06.06.2017 um 06:46 in Nachricht <CAKoqLCAfj+fDUMLfN4dLNSZ4NNAZpaSt_BWZRp+7XBqfhiSqiQ at mail.gmail.com>: > Hi Jean-Marc, > > I tried "==" before, and it failed when both results are 0.0. Maybe the > exponent or sign has difference because of the different 0.0 representation > in NEON. If anybody

Hi Timothy, Do you think it would be possible to improve the API of xcorr_kernel() so > that calling it in a loop is more efficient? > If it could be inlined, it will be more efficient. Besides memory bouncing, frequent function call is expensive. The other advantage to wiring up xcorr_kernel() is that it applies in more > places than your intrinsics-only celt_fir() implementation.

Hi, Attached is a patch for cosmetics purpose. Please review. Thanks, Linfeng Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170419/34354707/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cosmetics-silk-correct-input-output-arg-comments.patch

>>> Jean-Marc Valin <jmvalin at jmvalin.ca> schrieb am 16.09.2017 um 08:12 in Nachricht <29959506-9f3b-2ad1-fc02-2aea7c53c084 at jmvalin.ca>: > Actually, you're supposed to add /usr/include/opus to your include path. > That's why the includes don't have the "opus/" prefix. Hi! But that's uncommon: You also don't put /usr/include/sys into