It simply forces the higher minimum frame sizes and raises the lowpass filter, forcing the existing algorithms to "work harder" [..]
[..] which includes restricting extremely high frequencies to 17.5 kHz.
...So while we're asking questions about the working: does raising the lowpass a bit again (like --lowpass 18600), does that hurt the quality or does it only raise the bit rate.
What you describe is pretty much what 3.99.5z does when you use -V0+.
Halb, you mentioned that LAME 3.100 is in development right now - is Robert making that version available somewhere for testers? Based on the changes you've mentioned in that version, I wouldn't mind using it instead of 3.99.5 for ripping my old CDs, even if it is still being tested.
@BFG:The more you go to the limits the more often accuracy demands cannot be fulfilled due to lacking data space and due to the priority of keeping bit reservoir large for the sake of short blocks. In this respect minimum audio data bitrate of 290 kbps for long blocks is already pretty high (and overkill in 99.99..% of situations). What exact values to choose for -V0+ is more a matter of taste than a science. If you prefer higher values: go ahead but don't expect a noticeable different bahavior.As a side note: don't think in terms of frame bitrate, audio data bitrate is what counts. For audio data there's no 320 kbps limit, but there's always a limit of available audio data space (which -Vn+ tries to maximize, but it can't work miracles depending on the encoding situation).
...I suspect, in the end, that the only way to answer these will be for me to do some ABX tests.
Absolutely. I very welcome this. As you can see from my signature, I personally prefer another solution.
I did a short test (I am about to leave home) with your setting for lead-voice and trumpet_myPrince, and yes, it sounded fine. I didn't expect that from --adbr_long 110.I will investigate this further.
ABC/HR Version 1.1 beta 2, 18 June 2004Testname: 1L = D:\Audio\Test samples\eig\LAME 3.99.5z V3.wav2R = D:\Audio\Test samples\eig\LAME 3.99.5 V1.5.wav---------------------------------------General Comments:---------------------------------------1L File: D:\Audio\Test samples\eig\LAME 3.99.5z V3.wav1L Rating: 4.01L Comment: ---------------------------------------2R File: D:\Audio\Test samples\eig\LAME 3.99.5 V1.5.wav2R Rating: 3.52R Comment: ---------------------------------------ABX Results:D:\Audio\Test samples\eig\LAME 3.99.5z V3.wav vs D:\Audio\Test samples\eig\LAME 3.99.5 V1.5.wav 5 out of 5, pval = 0.031
Any chance for bitrates in range of -V5 ... -V2 in a future?
I haven't tried --frameAnalysis but I was thinking more about digging into problem samples to try to detect certain problems like highly tonal signals during short blocks and coming up with a detection algorithm that could be rolled back into general LAME VBR codebase, which means that the original PCM, the MP3 decoder output and the FFT analysis spectrum would be useful pointers - and just the sort of things mp3x provided, IIRC.I had the impression that mp3x was once very closely linked to LAME encoder up until around 3.90 time (especially before Dibrom's --alt-preset standard work when early investigations were tuning it from poor performance against the then best-in-class like FhG). But I suspect mp3x now is more than just a compile-time switch in the lame codebase, and would probably need an unjustifiable amount of work to get it running. Maybe if I find time to look into this, I'll set up a compiler, possibly under Linux until I can build a current standard LAME compile or the 3.99.5z version myself, then I can break out at short blocks and dump out the info I'm interested in to plot in LibreOffice Calc (or MS Excel) and try tweaking the code to trigger extra high bitrate only for problem samples and perhaps generate some samples artificially to ABX the correct threshold in the absence of other variables. I might even search for a very old mp3x version and see if provides enough info to germinate some ideas before I put in the effort of getting myself set up to compile the current LAME code frequently.I'd be hopeful that it must be algorithmically determinable, and thereby of cracking a few of the problem samples like trumpet and Angels Fall First by specific analysis used only when short-blocks are active, and of doing so without increasing LAME VBR bitrate on general currently-transparent music. It clearly won't help herding calls, which only uses long blocks. Presumably that either needs a different short-block detection threshold (unlikely from the sound of it) or needs more bits in the long blocks for some frequency resolution reason that the psymodel is missing.This work might be some time away, as I have too much going on in life for now, but I'm quite keen to give it a go in some downtime.
I was asked to provide more parameters. So I have been thinking about a new version for which there are more questions.