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.

[audiamus]

Right. Now the log says VBR off and no bit rate reduction. And it says transcoding runs as a copy. (The status line in the main window will always report this phase as "transcoding".) It's still FFmpeg that is taking so long.

Could this be a low memory issue? Or a relatively slow CPU? How long does an AAX file of about 10 hours take to convert to M4A with these same settings? This we could compare to the table in chapter 2.6.

It shouldn't go through the "detect silence" phase with your settings, though. That could be a bug.

[Sailfish]

Attached are:
o CPU-ZSystemInfo.jpg - CPU-Z screen capture of my CPU and Memory tabs
o ABondBrokenPass1&2.jpg - screen capture of AAXAC during Pass 1 & 2
o ABondBrokenConversionTime.jpg - screen capture of conversion time.
o AAXAC "-Log=3" log file of conversion



AaxAudioConverter_2021-02-25_001ABondBroken01.log

[audiamus]

Thanks.

Same kind of slowness for the shorter book, so it's systematic. We can rule out CPU and memory as a possible cause. Yours is much more powerful than my lab system on which I did the test series.

Your AAX files appear to come from an external disk. But I would not expect that to be the reason either. You could try to copy the input file to an internal disk first, for comparison. I do not expect much change, though. In my tests I feed the AAX files from a NAS system, and that's not a problem. Strange phenomenon.

And the silent phase is indeed obsolete for these settings, I have checked and can reproduce it. This particular combination is misinterpreted, unfortunately. At least we have found that out here. On my bug list now.

[Sailfish]

Attached is a screen shot of my Win7 drives. My OS C: drive (contains Win7 OS files) is a relatively small (256GB) internal drive while my I: drive contains my program data files (audible, spreadsheets, music, video, &c.)

I suspect this may be a recently introduced happenstance since I had converted aax files in past versions and not incurring the transcoding pass and, as you have stated, it was extremely fast.

[audiamus]

OK, not the disks, either. Has to remain unsolved for now, as it seems.

But you can skip the silence phase by setting "Use named chapters" to "no". You don't have them anyway as your downloads are with Audible Manager. So you don't miss anything. It won't help much so.

[Sailfish]

Confirming that setting/disabling the "Use named chapters" to "no" did remove the Pass 1 "silence" process and the conversion immediately went into the "transcoding" phase, saving about a minute processing time from before.

Audible Manager no longer works. However, since I'm not interested in named chapters, this will not be an issue.

Thanks, again.

[Sailfish]

Thinking a bit more on this, I uninstalled v1.16 and reinstalled v1.15.3.0 and ran it again. It processed the 1.83GB file in 30 seconds.

I hope this helps.
Attached are the screen shot files as well as the log file that tell the tale.



AaxAudioConverterV1.15.3.0_2021-02-25_001TheLastHunter.log

[audiamus]

Yes, I ran a few tests myself again and came to the same result. I am not normally using single file mode or conversion to M4A/M4B. So my previous tests for the release of 1.16 were just to ensure that all modes still work. The difference between 1.15.* and 1.16 in this area is FFmpeg. The new 64bit variant of FFmpeg now in use is definitely much slower than the older 32bit variant. However, the 32bit variant may not be able to convert very long books to MP3. I think the threshold is something like 40 hours. Your example is still below that.

[Sailfish]

I understand. For your consideration:
Since the ~40+ hour title seems like an outlier in the vast majority of conversions, could the program default to the 32bit FFmpeg and if title(s) are detected (either in single or batch mode) notify the user that it/they should be processed using 64bit AaxAudioConverter mode or something along those lines?

[audiamus]

could the program default to the 32bit FFmpeg and if title(s) are detected (either in single or batch mode) notify the user that it/they should be processed using 64bit AaxAudioConverter mode or something along those lines?

Something like that, yes.

For the moment, if you still have 1.15.3 available, copy FFmpeg.exe (C:\Program Files\audiamus\AAX Audio Converter) to a safe place, upgrade to 1.16 again and set the "Path to FFmpeg" (Basic Settings, General tab) to the location where you saved the 32bit FFmpeg.exe. 32bit builds of FFmpeg are hard to find these days, since the two semi-official binary sources for Windows don't make them anymore. But I can't tell whether it's 32 vs 64 bit - which I doubt somewhat - or some source code change they made in the last year.

[Sailfish]

The attached image provides run times made from several runs on the large sized, 199 chapter title using both the 32bit and 64bit FFmpeg modules. Interestingly, The 32bit FFmpeg outperformed the 64bit version in all but the single MP3 conversion. I hope you find this useful.

[audiamus]

Very helpful indeed. So we probably don't need an extra option. The program can select the suitable FFmpeg version based on book data and conversion mode. I will have to check FFmpeg memory consumption for the long book threshold because that was the reason to bring in 64bit in the first place.

[Sailfish]

Okay. if you need the use of a alpha/beta tester in the future, don't hesitate to reach out to me.