Can foobar2000 do what you're looking for? Could you try it with Wine?
- Changed volume control handling to better match with foobar2000 volume control behaviour.Hopefully it scrolling could also follow volume step setting of foobar2000
Thank you very much for the technical explanation--as a fellow (amateur) programmer, I like to know technical details about how stuff works (or doens't work )
I have thoroughly read the user manual before finally deciding on the parameters that I would use, and I did see the -cc option. In the manual, it says that it "tells WavPack to optimize for the overall compression ratio instead, even if this means some possible degradation of lossy quality". Honestly, I would have used it only if it didn't say that "the effect of this option is not too significant either way"
Sure, I'd reencode all the WVs with -cc if it reduces file size significantly. (It'd take me a bit more than a week of waiting as my Intel Celeron laptop converts 24 hours a day, but I will reencode if I need too--I really need HD space ) As I said, I don't mind hearing lossy artifacts during lossy decoding--in fact, I kinda love hearing those, I don't know why, but I guess it reminds me of how complex audio codecs are and it makes me impressed that this works
However, what do you recommend? Do I reencode my whole collection to -ccx6 or, do you think only these high-resolution files are worth reencoding? What is the probability that a normal CD-quality file will get huge benefits from using the -cc option?
Again, thanks for your response, I really appreciate it
OrthographicCube sent me a sample of the files that were resulting in worse compression with -x6 (thanks!) and I have performed several experiments and think I have a good idea why this is happening.
Yes, the -x6 mode is a little worse than -x1 (or even no -x), but that is actually a minor issue (and one I don't really understand). A much bigger issue is just how bad the compressor is working here, and I have figured out that it is caused by a combination of the very low target bitrate being used and the fact that it's a 96 kHz file.
When WavPack encodes hybrid at 96 kHz it uses aggressive noise shaping to move noise up out of the audible range. This normally works okay; it results in slightly worse overall compression and noise, but reduces the audible noise a lot. However, at this low bitrate the noise is being amplified by the decorrelation filters resulting in huge amounts of extra noise and really bad compression. I have seen this before in some special circumstances, but never really thought that it would happen this bad with just regular 96 kHz audio.
Fortunately, the fix is pretty simple. There is an option -cc that replaces the regular -c. This eliminates the heavy noise shaping that is causing this issue and on this test file reduces the noise by almost 14 dB, and improves the compression by almost 10%! I know it's time consuming, but I think it would definitely be worth reëncoding the 96 kHz files like this. They'll be a huge amount of space saved in the correction files while leaving the lossy files about the same (except with less noise). Another fix would be to keep the aggressive noise shaping and increase the target lossy bitrate to a more reasonable value, say -b3.5. Of course, that will result in bigger lossy files.
I'll do some more investigation, but at this point I'm not sure what to do about this. It's not really a bug, but I can imagine other people having this issue and not even really knowing it's happening. After all, this was only noticed because of the odd -x6 behavior (which does go away with either of the above fixes), but the real problem is the really bad compression with low bitrates and heavy noise shaping.
MusicBrainz Picard?OK, luckily this one's also in my distro's repos. I've had a quick look, and it's also just a tag editor caring about the typical, file-wide metadata, like author, data, year of release, track numbers, and things like album art.
But again, it doesn't seem to be able to understand stream related information. I cannot set the stream language, or things like stream order, etc.
As I see it, MP4 holds three versions of tag information, or at least three widely supported sets of tag information.
These are the ones used by iTunes, ISO defined tags, and 3gpp defined tags. They seem to overlap in some but not all.
I still haven't exactly wrapped my head around how the metadata is stored. As I understand it, it's technically a tree structure that is stored somewhere in the file, but MP4 seems to be able to contain more than one format for metadata.
Maybe I'm barking up the wrong tree, and should find out more how MP4 files store file and stream information first...
If this leads to nowhere I'll see how libraries read that file information. lavf should be able to get the full complement of all MP4 metadata, I'd imagine.
yes, I have been. I just tried both of them and can see nothing from Fanart, even though I double checked that they have the cover I need.I registered to say that the fanart.tv script is again broken and I'd very much appreciate a look at it since it's one of the better ones in the bundle.Were you using the version I posted here: https://hydrogenaud.io/index.php/topic,57392.msg914440.html#msg914440 (or the other one I posted a few messages below that)?
If anyone is interested, I have written a small command line r128gain scanner/tagger implementation to fill the lack of such tool.
Its written in Python and uses FFmpeg for decoding and R128 loudness analysis.
* writes tag using the ReplayGain format (follows ReplayGain v2 specification), or the R128_XXX_GAIN format as described in the Opus RFC
* should work with any file/tag format (my automated tests cover AAC, FLAC, Opus, MP3, Vorbis, WavPack)
* extremely fast (compared for example to vorbisgain) by using file based parallism and/or FFmpeg threaded decoding
I still have a few features to add before releasing a v1.0, but after a few weeks of testing with different file formats, both as a command line tool and a library for some of my projects, it seem to work quite well.
It's not a lot a code and I use it myself frequently so I intend to maintain it in the long run.
It's quite possible to come up with a graph that tries to be more exact rather than heuristic. igorc's graph from 2014 would be more of a starting point for such an endeavor. It'd need to be updated for Opus 1.2, and it would benefit from more listening test evidence.
Because some codecs' performance depends so much on the difference, one really would need at least two separate graphs - one for fullband stereo music and one for speech.