Comments (26)
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
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 |
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
from aaxaudioconverter.
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.
from aaxaudioconverter.
Cannot format using this textbox. See attached text file
AudibleTests.txt
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
Conversion speed depends mainly on two factors.
- How much of the work can be parallelized? Nothing, if it is one single-part book in single file mode.
- 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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
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
from aaxaudioconverter.
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?
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
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
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
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
from aaxaudioconverter.
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.
from aaxaudioconverter.
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?
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
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.
from aaxaudioconverter.
Okay. if you need the use of a alpha/beta tester in the future, don't hesitate to reach out to me.
from aaxaudioconverter.
Related Issues (20)
- Titelnummer bei Dateinamen hinzufügen HOT 2
- IOException: [file name] issue HOT 10
- AAX Audio Crashes but Book Lib does not
- Semicolon instead of colon HOT 2
- Insufficient Number of FFmpeg Processes Started during Conversion HOT 2
- MP3 Compression Settings Leave Hiss on Output HOT 5
- Windows 11 ARM installer support? HOT 4
- Conversion Hangs Creating Multiple Files by Chapter HOT 9
- Mac or CLI version ? HOT 1
- Loosing Last Few Seconds of File HOT 1
- AAX aborts during conversion HOT 10
- The "MAPS" "chapter" that's included sometimes seems to be corrupt HOT 6
- Conversion Hangs Creating Multiple Files HOT 17
- Single file per AAX file: Metadata track numbers for all tracks/chapters are set to "1" HOT 8
- Numbers being prepended to file name HOT 2
- Is it possible to split to MP3 by narrator? HOT 1
- Activation error HOT 1
- accept .mp4 extension HOT 3
- Idea: file splitting for mp3 HOT 1
- Add support for the arm version of Windows HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aaxaudioconverter.