Last post by Case -
If ffprobe reports bit-depth you will see it in the properties. I turned a test m4a file into mka with MKVToolNix GUI and bitdepth was reported as zero by ffprobe and foobar didn't show any incorrect info either.
Last post by Radosny -
Guys, I hope it is just simple solution. I just can not believe it would work like that. I can not open any file that has not been closed yet. (to which the data is still being saved by another program)
Aimp, Xmplay, 1by1 even winamp have no problem in such a situation. I have downloaded foo_winamp_input_050309 to enable some winamp input plugins but before I start implement such an exotic solutions I ask You: Am I doing something wrong? please help
Last post by Porcus -
Played around with remuxing .opus into .mka , and found that foobar2000 reports them as 32 bits. Repeated with AAC and Vorbis: 32. (Same with webm.) Repeated with an .mp3: 16, so it is not consistent.
Then I dug up some old (-> might be older ffmpeg?) Matroska files with AAC, and found them to be reported as 16.
For all that I know, ffmpeg could write misleading information to the container. Tried ffmpeg 4.0.2 and 3.4. Could anyone reproduce?
Last post by Gadgety -
I use the default interface. When I launch a VST component they launch in the upper left hand corner. This obstructs the top part of the interface, where the playback functions are in located. Can the location of where the VST components are displayed upon launch be changed?
Last post by rectifica -
I don't have equipment as such and would like to save file space while retaining quality. I've had a look around and VBR Q 45 w/ 96khz looks to be sufficient. I don't mean to generalize since everybody's ears are very different to the next, just wanting to know what you settings you use!!
Last post by j7n -
Why does opusdec.exe include OpenSSL? Doesn't this belong in a program that connects to the web, like a streaming player or browser? No other cli audio decoder has web components in it.
Last post by j7n -
Recent Foobar versions have a configurable advanced setting for ReplayGain in Opus. The program can either store it in the global gain header field or a tag, it can also clear the header gain field. Album gain written to the global gain field, as happened by default in the past, wouldn't cause sudden jumps in amplitude, since the gain would be the same for all tracks. Glitches due to changing track gain happen in all formats. There was a proposal by Frank Klemm for a gradually changing AGC type of track gain, but it was never implemented.
For music with extreme sub-bass, either sourced from vinyl or artifical electronic music, you could prefilter it with a highpass filter, so that the mandatory Opus HPF does very little. This is far from ideal, but is one way of addressing the issue.
Last post by 40th.com -
A critical problem with opus is the single entry for a replaygain-like value. No separate track and album values, just the one, and no way to say if it is track, or is album, or is who knows what. It defaults from what I've seen to 5 dB (from memory, and I suppose that is minus 5 dB) regardless the source. If you use something else to calculate a replaygain value, that value is stuffed into the single entry available for an opus track. It's not a tag, like replaygain is in .ogg, or .mp3, but a little cubbyhole for that value. It's a disaster since there's no telling what the value is for (album or track), and if you go by the opus docs, it's required to be used.
FWIW, even if you have already adulterated the track with a replaygain scanner, the player in the link below plays opus tracks gaplessly ("no glitches" by definition then), but you have to remember to keep RG off (using the RG button). Still, this is one reason I can't take opus seriously for music because RG is important. It needs both track and album RG-value slots.