Encode VBR MP3 (plus FFmpeg performance)

[kettenfett]

It would be nice, if the program could be set to encode variable bitrate (VBR) MP3s, rather than CBR.

VBR can be up to half the size of a corresponding cbr file/audioook. Plus, VBR is widely supported.

For audiobooks, I'd use V5, which will result in ~130kbps average bitrate, which is more than enough for spoken language.

[audiamus]

I will have a look at this. AAX files come with either 64 or 128 kb/s CBR. By default, FFmpeg takes this same CBR when transcoding to MP3. With VBR, the actual output quality setting should be related to the input CBR.

If VBR becomes an option, it should also be made available for AAC, where the VBR quality argument is in a different value range. Any experience here?

It will slow down MP3 transcoding, I presume. Definitely so for AAC, since that's just a decode & copy operation with the default settings.

[kettenfett]

AAX files come with either 64 or 128 kb/s CBR

I got a couple of books that came in 32kbps actually. I just checked, and AaxAudioConverter converted them into 32 kbps cbr mp3 accordingly. Nice.

With VBR, the actual output quality setting should be related to the input CBR.

You can use this table to find matching ffmpeg parameters for target average bitrates in VBR mode:

LAME Bitrate Overview
lame option | Average kbit/s | Bitrate range kbit/s | ffmpeg option
-b 320 | 320 | 320 CBR (non VBR) example | -b:a 320k (NB this is 32KB/s, or its max)
-V 0 | 245 | 220-260 | -q:a 0 (NB this is VBR from 22 to 26 KB/s)
-V 1 | 225 | 190-250 | -q:a 1
-V 2 | 190 | 170-210 | -q:a 2
-V 3 | 175 | 150-195 | -q:a 3
-V 4 | 165 | 140-185 | -q:a 4
-V 5 | 130 | 120-150 | -q:a 5
-V 6 | 115 | 100-130 | -q:a 6
-V 7 | 100 | 80-120 | -q:a 7
-V 8 | 85 | 70-105 | -q:a 8
-V 9 | 65 | 45-85 | -q:a 9

source

So I think you can use V5 for 128kbps input, V9 for 64 kbps input, and for 32 kbps input you use either V9 as well or keep 32kbps CBR.

A similar table for AAC also exists:

VBR	kbps/channel
1	20-32
2	32-40
3	48-56
4	64-72
5	96-112

source.

The referenced articles also explain, how VBR encoding is done with AAC/MP3 in ffmpeg.

It will slow down MP3 transcoding, I presume. Definitely so for AAC, since that's just a decode & copy operation with the default settings.

I think if it's not the default setting, it will be fine. People who know what VBR is, will find it in settings.

[Sailfish]

VBR would be an excellent addition and would almost guarantee I would use your program to backup all of my audiobooks to a portable storage device. Most of the .aa & .aax files are of a single narrator and as kettenfett mentioned, don’t require the quality of the 128kbs and could easily sound just as good at 32kbs or even lower; thus allowing a more efficient use of backup storage.

[audiamus]

Even so, since AAC only flags a dozen or so .aa files, it very well may be something strange about just those.

As this does not seem to be related to VBR, could you open a separate issue for this?

For that new issue, can you also run your AAX Audio Converter session for .aa files with the log option activated and then upload the log file? Log level 3 should suffice.

[Sailfish]

Cannot format using this textbox. See attached text file
AudibleTests.txt

[audiamus]

VBR will appear in 1.16. Appears to work in my lab environment for both MP3 and AAC.

For AAC and the native encoder in FFmpeg the -q:a range is from 0.1 to 2.0, more or less the CBR in kb/s divided by 100. Using VBR for AAC makes makes a conversion a full transcoding operation, slowing it down significantly.

Stay tuned.

[Sailfish]

Feedback on v1.16 VBR vs. CBR setting
Source AAX: TheLastHunterCollectedEdition_ep7.aax 1.83GBs
OS: Win7SP1, CPU: Intel i7 6700K
Source Drive: Internal 3TB Seagate
Destination Drive: External 4TB USB Portable Seagate

CBR Destination Format: M4A, BR: No Variable bit rate, Time: 7:20 mins, Size: 1.8 GBs
VBR Destination Format: MP3, BR: 24kbs (lowest setting), Time: 8:00 mins, Size: 328MBs

Sound quality: No discernible difference.

[audiamus]

Conversion speed depends mainly on two factors.

1. How much of the work can be parallelized? Nothing, if it is one single-part book in single file mode.
2. What kind of operation: copy or transcoding. Generally speaking, copy is fast, Transcoding is slow.
   However, this picture can be altered significantly by other factors, like bitrate.

Without bit rate manipulation, AAX to M4A/M4B is a copy, so is AA to MP3. Crossover means transcoding.
But: Transcoding always kicks in automatically, if VBR is set. But not always if CBR reduction is set. In that case it only becomes a trancoding operation if the set bit rate is lower than the source bit rate.

If you combine CBR reduction and VBR, VBR is applied, with a parameter value approximating the given CBR. But there are limits, low CBR settings could be ignored if they exceed the maximum VBR compression.

[Sailfish]

Thanks for the additional information as to the copy v transcoding performance characteristics. It is insightful.

I regret not being more clear with the primary intent of posting my reply, though. Specifically, at least on my rig, being able to transcode AAX (m4a/b) to mp3 from an almost 2GB file to a 328MB file (~82% reduction) and only incurring a 9% performance penalty along with no noticeable loss in listening quality is absolutely phenomenal. While my preferred listening mode will still be with my .aa/.aax files, using AaxAudioConverter for backup and lending itself to an hierarchical library structure is very appealing.

As I've mentioned in the past, I have over 1100 Audible titles consuming 600GBs. Even though I've only tested this on one large AAX file, I plan to perform a much larger experiment in the future and am willing to provide the results if you would find them useful. If so, please don't hesitate to let me know if you have any suggestion(s) on experimental runs that might prove insightful when performed on a large set of titles.

[audiamus]

Your observations still confuse me.

Converting from AAX to M4A should take only seconds for a normal size book of a few hundred MB, single file mode, no silence detection, no chapter mark adjustment, no intermediate copy, no 44.1kHz patch, original bit rate. And that figure should not explode if the book is four times as big. I wonder what is taking so long. A log file, level 3, could hold the answer.

VBR for MP3 may reduce transcoding time somewhat or may not. Haven't done any test series. It will definitely lengthen the conversion if it had been a mere copy otherwise.

In the manual, chapter 2.6, there is table with timings from test runs for the different modes for two typical books, with original bit rate. Your M4A figure doesn't really fit in. The only explanation I have at the moment is that it could be the post-processing step which adds the Quicktime chapters. Again, a log file would reveal it.

[Sailfish]

Attached are the following files from the AaxAudioConverter run:
AaxAudioConverterJobDoneTime.jpg - Image of completion Time
AaxAudioConverterJobOutputFileList.jpg - Image of Windows Explorer Output Folder
AaxAudioConverterJobScreen.jpg - Image of AaxAudioConverter Main Screen
AaxAudioConverterSettings.jpg - Image of the Basic Setting 4 tabs
AaxAudioConverter_2021-02-24_001_USB_DRIVE.log - Job log with "-Log=4" run switch

Note: No noticeable difference in completion time when set to m4b output

AaxAudioConverter_2021-02-24_001_USB_DRIVE.log

[audiamus]

Unfortunately, the log file is with level 4, and due to the massive FFmpeg output from this level, it's incomplete, as it exceeds the internal 20MB limit per file and will have spilled over into the next log file.

Nonetheless, at the beginning of the log we can see the conversion parameters used for this run (from line 667):

:IAppSettings:IConvSettings:INamingAndModeSettings:IModeSettings
    ConvFormat = mp4
    ConvMode = single

:IAppSettings:IConvSettings:IBitRateSettings
  VariableBitRate = True
  ReducedBitRate = _24k

However, the bit rate settings in the log conflict with the settings in your screenshots of the settings dialog.

Are you sure you reset the bit rate settings before you ran the conversion to M4A?

[Sailfish]

AaxAudioConverter_2021-02-25_001TheLastHunter02.log
To doubly insure, I reset the Settings via the Reset button and returned the settings to the figure I uploaded before and the transcoding was still invoked. As before, it makes a first pass going through all the chapters (45 secs) and then immediately transitions to the transcoding process. I'm including the log file that was generated using the -Log=3 run switch.

I also made a run using another .aax file with the same settings and it also went started transcoding after the first pass.

Please let me know if I can provide further information.