I've been building my digital media library from my DVDs and Blu-Rays, but I've begun to question the audio decisions I've made.
When it comes to Blu-Rays, I have been keeping the DD or DTS core, rather than the "HD" track, mainly due to the difference in filesize.
I've not been converting them, just leaving them as they are.
I've recently been experimenting with taking the HD track instead, and converting to AAC using Nero converter in EAC3to
I've used the maximum quality setting (1), which tends to generate an average bitrate of 750-1000kbps.
Typical command line : eac3to test.ac3 testresult.aac -down6 -quality=1.00
(This also takes the channel count from 7.1 down to 5.1, which isn't an issue as I do not intend owning a 7.1 setup, and 7.1 AAC seems to have compatibility issues on different equipment)
I know the best judge is my own ears, but I'm interested to hear other people's thoughts too.
To me, doing the above process provides an improved sound experience over the core tracks. In some cases the core track is a higher bitrate, but still doesn't sound as good.
Is it my imagination, or is this due to AAC having better compression algorithms, and therefore providing a better sound quality from the same or less space?
Is it worth switching to AAC conversions of the HD tracks, or should I just continue using the Core tracks without recompression?
Should I be aware of any additional parameters to use in EAC3to that could make a difference?
Look forward to reading your opinions!
+ Reply to Thread
Results 1 to 15 of 15
AAC has wider compatibility for playback due to license fees. By sticking to AC3, you risk your library not having sound at a later date, when using another device for playback.
AAC codecs like Nero or Apple are considered to be the best for AAC in general, with Opus being considered better than anything else. But Opus is part of a separate non-AAC format and so some devices might not support it, even though it's royalty-free. DTS has really poor compression, which they advertise as a feature, and so that audio file can be massive. AC3 encoded by a Dolby encoder has much better efficiency but is still less efficeint than a MP3. If you have lossless files then it's certainly worthwhile to convert them to AAC or Opus, instead of using the AC3 core or DTS core.
Last edited by KarMa; 12th Mar 2019 at 20:03.
Sorry for delayed response - thanks for the information. Really useful.
I've now got to begin the mammoth task of ripping the HD audio track for the 200+ Blu-ray I've already done!
Shame MAKEMKV doesn't let you rip only the audio track. Will have to check if there's any other options to speed it up a bit.
For NeroAAC I tend to use -q 0.50, as it provides similar bitrates to a typical AC3 stream (generally a little lower).
Mostly I use QAAC and --no-delay -V 91. No delay removes any encoder padding (silence at the beginning) and -V 91 results in similar bitrates to Nero's -q 0.50.
For me, the only point of re-encoding the audio would be to reduce the bitrate and therefore the file size. As a result I generally don't re-encode AC3 but for DTS the above settings will provide a decent bitrate reduction.
You can't improve the quality by re-encoding, but do many receivers support AAC passthru (are there many that will decode AAC as well as AC3 and DTS)?
Not that I care, as I use my PC for playback and it decodes the audio so I don't have to worry about sending raw AAC to a receiver for decoding.
Yes I use my PC for playback too (generally) so the AAC 5.1 tracks work for me.
I wasn't planning to re-encode any DD or DTS lossy tracks. I am just keen to use the "HD" (i.e. lossless) tracks from the Blu-Ray to get the best quality for the bitrate. 3-4gb per film for just the soundtrack is going to take up too much space for me, but an AAC track at around 800mb, which provides better quality than the core DD or DTS tracks seems a sensible compromise for me.
Not sure I want to remove silence from the beginning of the tracks though - it'll throw the films out of sync!
MKVToolNix will account for it when muxing (if the information is available in the MP4/M4A file), so if you check some MKVs with AAC audio and you have any with an audio delay of around 9 ms (for NeroAAC from memory) it means MKVToolNix deleted the padding, and a bit extra (because lossy audio is contained in frames) and then it applied a small delay to make up the difference. I'm not sure if MakeMKV does the same.
QAAC has a --no-delay setting which prevents the padding, so there's no delay. As long as the muxer accounts for any padding though, it's no big deal either way. If it doesn't, it means the audio will be delayed somewhere in the vicinity of 50ms, which isn't too huge a deal.
--no-delay Compensate encoder delay by prepending 960 samples of silence, then trimming 3 AAC frames from the beginning (and also tweak iTunSMPB). This option is mainly intended for resolving A/V sync issue of video.
Ah OK I think I'm with you now. I had noticed that when remixing the tracks with mkvtoolnix that I was having to add a 100ms delay to the audio track to keep it in sync.
Provided it's consistent (I. E. Always 100ms) then it's not a major issue for me, but I might check out QAAC to see how it compares.
If you add the .m4a straight from Nero and put it in mkvmerge it should detect the delay and silently make up for it like hello_hello said. If you manually enter "100ms" as delay you would add an additional delay, making the file async. Only if you demux the m4a the delay information is lost and you have to manually make up for it. And even then you would have to use negative values!
Delays for NeroAacEnc:
LC: 2624 * 1000 / sample rate
HE: 2336 * 2000 / sample rate
HEv2 2808 * 2000 / sample rate
So for example with HE profile and 48 kHz sample rate:
2336 * 2000 / 48000 = 97.33333... ms delay
What's the best AAC encoder?
At sensible bitrates, you'd probably need bionic ears to tell the difference between QAAC and NeroAAC.
QAAC does have some command line options that might come in handy now and then though, such as --gain for adjusting the volume or --delay for applying a positive or negative delay to the encoded audio.
I'm encoding with Eac3to with the Nero plugin. Perhaps that doesn't enable mkvtoolnix to see the delay?
I've had to put a 100ms delay, to get it in sync, and that's for the first 5 movies I've done.
I'm quite sensitive to sync issues,so spotted it very quickly!
Also, the encodes I'm doing are flagged in mediainfo as AAC LC. Is this OK or should I be setting something different?
Probably process, as I have played the files in pc and in UHD bluray player and they are in sync.
My ears are not at fault, that one I can guarantee!
To clarify, this is the process I'm following:
Possibly something to do with the fact I'm remuxing the resulting aac file back into the original conversion I did about 2 years ago?
My process chain hasn't changed much though.
1) Makemkv to rip the movie (originally with core audio but now with HD)
2) demux HD audio track with mkvextract (not required before)
3) convert video stream with handbrake (used to passthru core)
3) convert audio to aac with Eac3to / Nero plugin (not required before)
4) remux with mkvtoolnix. (not required before)
I used to get occasional a/v sunc issues with the process before - never knew why, but as I could adjust it quickly with mkvtoolnix it didn't bother me greatly.
Can't you convert to AAC without extracting the audio?
A command line to convert the audio to AAC would look something like this (assuming the audio stream is stream #2):
eac3to.exe "E:\RippedMovie.mkv" 2:"D:\RippedMovie.aac" -down6 -quality=1.00
If there's an audio delay relative to the video, eac3to will remove it by adding silence.
Does MKVExtract inform you of any audio delay when extracting audio? If not, try gMKVExtractGUI or MKVCleaver instead. They write any audio delay to the file name so it can be applied for the encoded audio when muxing. ie
I was actually using MKVextractGUI. Sorry should've said that.
Thanks for the tip I converting the audio within the mkv. Didn't think of that!
Also, I tried my first "from scratch" conversion last night (i.e. Video stream converted now, rather than adding the newly converted audio to a previous conversion). Perfectly in sync, so it must be something to do with combining the audio with the previously encoded video stream.