similar to: No subject

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

Martijn van Beurden wrote: > No, there is not. To make sure the encoding and decoding > processes are lossless, there are no switches like these. You > will have to use another program, like SoX, to do this. I was not aware this behavior was considered lossy and I didn't know that only lossless encoding and decoding was a goal. Specifically, I thought extracting only some channels

Hello, I have a large collection of audio files contains music in mp3 format, due to need to free space of hard disk, I need to reduce their size. It seems opus is the best format for this purpose, in order to have the quality of original mp3 files, currently I use ffmpeg command to convert them to FLAC and then use opusenc, the official opus encoder, to convert FLAC files to opus. By using one

Situation:? * remote virtual server with very little storage (estimate: I can spare about 40G for music) * local music collection of ~80G in all sorts of formats - lossy in varying quality, some lossless too Vision: * stream my whole music collection randomized so I can listen to it anywhere Plan/Idea: * Locally transcode everything to one format that results in files that are?

Opus or AAC will give you comparable results at reasonable bitrates (~128k). Though, I would suggest finding a way to get more storage. You could upload to Backblaze B2 or AWS S3 for pennies, if your current host won't let you upgrade. On Sat, Apr 15, 2023 at 3:36?PM D.T. <ohnonot-github at posteo.de> wrote: > Situation: > > - remote virtual server with very little

Could you add ReplayGain calculation to opusenc?

I created some test samples and transcoded to FDK AAC and libopus at fairly low bitrates - I cannot recreate what bothered me about Opus & noisy music previously. It also seems I cannot tease ffmpeg into encoding FDK's AAC with VBR. As it stands, Opus clearly wins in this scenario.* Q: Is it possible to stream in variable bitrate? * ffmpeg -i "$track" -vn -ac 2 -c:a libfdk_aac

using iTunes i've noticed that AAC is very good at re-encoding own lossy sound. let's test Opus! neroaacenc.exe -q 0.75 -if 000.wav -of 001.m4a neroaacdec.exe -if 001.m4a -of aac001.wav wavdiff.exe 000.wav aac001.wav Comparing 000.wav - aac001.wav... Max diff: -17.3867dB RMS diff: -33.0851dB Mean diff: -32.4582dB opusenc.exe --bitrate 512 "000.wav" 001.opus opusdec.exe 001.opus

Opus is specifically designed to survive tandeming but you need to keep the frames aligned and not mess with the gain, which your tools probably do not do. On Thu, Nov 16, 2017 at 10:58 PM, encrupted anonymous < sergeinakamoto at gmail.com> wrote: > using iTunes i've noticed that AAC is > very good at re-encoding own lossy sound. > let's test Opus! > > neroaacenc.exe

Hi all, I have implemented ReplayGain support for Vorbis. If you are not familiar with it, it is basically a method of making sure all your files have equal loudness, remove the need for normalization and prevent clipping during playback. The process is totally lossless, and supporting it requires minimal work. More info about the exact workings can be found on www.replaygain.org (recommended

When a locale is in effect that does not use the point as the decimal mark (e.g., sv_SE or de_DE, which use a comma) and a ReplayGain tag is read for --apply-replaygain-which-is-not-lossless, the gain value was misinterpreted (e.g., "-2.29" truncated to "-2"). This is fixed by resetting the locale to "C" temporarily, based on Josh Coalson's fix of the dual case

This patch to opus-tools adds optional support to WavPack lossless format as input to opusenc. Like support to FLAC, it depends on an external library, libwavpack, and may be disabled on configure. Lucas Clemente Vella (1): Reading input from WavPack files. Makefile.am | 7 +- configure.ac | 37 ++++++++ src/audio-in.c | 71 ++++++++------- src/opusenc.c | 19 +++- src/opusenc.h

>> ..But sadly none of FLAC, WavPack or OptimFrog could compress the >> pre-processed song better, or hardly. And considering you'd also >> have to add >> the pool of frames, it would end up worse. > > This surprises me. Have you tried aligning your frames to the > standard FLAC frame size? > Not at all, because I have no idea how it works internally,

--- CE <ce7@sbcglobal.net> wrote: > I'm hoping to set up a headless system to playback my audio once I > get back home after an extended leave. Ideally I'd just ssh in and > use a curses based player to play back FLACs and mp3s. This leads me > to a few quesitons: > 1. What is the minimun processor speed needed to decode and play > flac files? I have an old

Monkey's Audio lossless compressor (currently win32 only, free but not open-source except decoder) author is thinking to implement a kind of audiophile-quality lossy compression which would filter "noise bits" that are hard to encode lossless but which are (or should be) inaudible and thus improve lossless compression (avg. 300-450kbps). I think that implementing something like this

A few comments: 1) Many embedded devices that have FLAC support only handle a subset of the FLAC capabilities. It seems highly unlikely that an embedded device would have the ability to parse Vorbis file format wrappers around FLAC data. In other words, depending upon how broad you want the support to be, it might be best to make this addition to FLAC rather than Vorbis. 2) In general, changes

Everything above 96kbps on that table is speculative, as the highest multi-participant listening testing done was at 96kbps. Here's the results from that test, if you're curious: http://listening-test.coresv.net/results.htm As you can see, at that rate Opus ranged from slightly perceptible to imperceptible. Also importantly, note how few of the donors were able to give significant

I am interested in being able to encode a single Opus stream using several CPU cores. I get a raw audio input and "opusenc" can transcode it at 1200% speed (Raspberry PI 3B+). It saturates a single CPU core, but the other three are idle. Is out there any project to add multithreading options to "opusenc", or something in that line? Looking around, I have found this:

I'm not aware of any other attempts, and there have never been official plans. It's difficult to partition input for opus at anything other than the track level, because of the way the decoder derives its adaptive state from recently-seen audio. I guess cutting together streams with at least an 80ms overlap wouldn't glitch too much? You could probably do something to try different

>>> Ralph Giles <giles at thaumas.net> schrieb am 30.03.2020 um 23:17 in Nachricht <11930_1585603054_5E8261ED_11930_50_1_c110a52d-de95-3bbb-35b2-eca12c79f143 at thaum s.net>: > I'm not aware of any other attempts, and there have never been official > plans. It's difficult to partition input for opus at anything other than > the track level, because of the way