Proposal to change default surround audio format and bitrate

[lisamelton]

Proposal to change default surround audio format and bitrate

Let me just cut to the chase...:) I propose that the default 5.1 surround audio format and bitrate of transcode-video be changed from Dolby Digital (AC-3) at 640 Kbps to Dolby Digital Plus (DD+ or E-AC-3) at 384 Kbps.

What!?

It is inevitable that our default surround audio format and bitrate will change. The only question is when. And I want to do that sooner rather than later.

Please remember that I'm only proposing that we change the default. Not to somehow disallow AC-3 at 640 Kbps. I'm not completely insane. :)

AC-3 is an ancient audio compression format, even older than MP3. Achieving transparency with it requires using close to its maximum bitrate of 640 Kbps. And that bitrate is more that 10% of our target video bitrate for 1080p content. That's just crazy.

What's even crazier is when you consider that, by default, each surround track is duplicated, i.e. transcode-video creates two output tracks, one in 5.1 AC-3 track at 640 Kbps and one in stereo AAC track at 160 Kbps. And that's a combined bitrate of over 13% of our 1080p target.

While this strategy is "portable," it has never been a good way to achieve my original "smaller" goal for the project. :/

So, our audio footprint needs to get smaller. And wouldn't it be nice if we could do that and improve quality at the same time?

I had hoped that we could transition to multichannel AAC audio since HandBrake and FFmpeg can already create 7.1 channels with it. But, other than desktop PCs, native 5.1 AAC support is only available on some Android-based devices while 7.1 support is essentially non-existant. :(

And it's clear that the PC, mobile device, TV and home theater industries are now supporting DD+ decoding or passthrough pretty much everywhere. In fact, that transition has already happened. So DD+ it is.

It's also clear that streaming services prefer DD+ as their surround format. In fact, Netflix uses DD+ exclusively for surround audio. They won't even serve up AC-3.

Which means those media files with surround audio that you "acquired" from your Uncle Torrance (you know who I mean!) are in DD+ format. :)

Why is DD+ so popular? Because you can get as good or even better quality with DD+ at half the bitrate of AC-3.

Did you know that all the streaming services use 5.1 DD+ at only 192 Kbps as their default, stepping up to 384 Kbps if you have a better connection and sometimes 640 Kbps if you have bandwith for video at 10 Mbps or more?

Here are the (more or less merged) surround bitrate guidelines from Apple and Roku for AC-3 and DD+:

Channels	AC-3	DD+
5.1 (surround)	384 Kbps	192 Kbps
7.1 (surround)	-	384 Kbps
Nominally 16 (with Dolby Atmos)	-	384-768 Kbps

Obviously the other reason for DD+'s popularity is Dolby Atmos support, which is unavailable in AC-3.

Anyway, DD+ at 384 Kbps seems to be the sweet spot, the best compromise between size and quality. And my own testing confirms that. It sounds just as good or better than AC-3 at 640 Kbps to me.

In fact, if I re-transcode a DD+ track at 384 Kbps to AC-3 at 640 Kbps, I'm hard pressed to tell the difference between that and an original AC-3 track at 640 Kbps. Which means I'm not even worried about any possible dynamic re-transcoding by my Plex Media Server.

Here's how I would describe this proposed change within the built-in --help output of transcode-video:

    --ac3-encoder ac3|eac3
                    set AC-3 audio encoder (default: eac3)
    --ac3-bitrate 384|448|640|768|1536
                    set AC-3 surround audio bitrate
                      (default for ac3: 640; default for eac3: 384)

So, to get the current behavior, only --ac3-encoder ac3 would be required on the command line. Thus making the transition easier.

Please try to create some audio yourself with DD+ at 384 Kbps and see how it sounds. I tested on multiple stereo and surround systems as well as high-quality stereo headphones using passthrough and even dynamic re-transcoding by Plex or explicit re-transcoding at the command line.

I would love to hear from @samhutchins, @JMoVS, @khaosx, @klogg416, @rhapsodians, @damorrison, @vr8hub, @dkoenig01, @ericcardenas, @arikalish, @RodBrown1988, @chrispoole643, @elliotclowes and anyone else from our various audio threads over the years or elsewhere about this proposal. Thanks!

[klogg416]

@donmelton
I have been maxed out for about 10 hours with transcode-video --avbr --audio-width all=surround --ac3-encoder eac3, I am already on the proposed page.

Two thumbs up from me.

[lisamelton]

@klogg416 Thanks for the quick feedback! Nothing like re-transcoding your entire video collection every month, is it? :) BTW, the current default bitrate when using eac3 will be 640 Kbps, but it's not like that will somehow sound bad.

[khaosx]

@donmelton If we want to do a couple of test transcodes to see what this is going to sound like, are we good with using @klogg416's --ac3-encoder eac3 --ac3-bitrate 384 or is there some other special sauce we need to add?

Also...damn guys, what's your average frame rate and library size? We keep mentioning re-encoding libraries and I'm here like "Yeah, unless I tear down my ESX box and boot it with Linux, I can do about 15 movies in the 12 hours I'm not using my system. And even if I do that, I can only run 3 encodes at once on the server!"

[klogg416]

Huh, so it is. I am not going to lie to you, continuing to add the same 10% more data for even better eac3 is totally fine with me. Pretty much all my source files are FLAC versions of some HD surround encode, and the idea of better eac3 for the same price I have been paying all along sits well. It wasn't so long ago that I was just using --copy-audio and adding 50% to the file size... :-|

Similar to how when you find an improved way to squeeze more quality out of the video encode at the same target bitrate, you keep the bitrate the same and take the quality instead of aiming for a the old quality at a lower rate, I am not sweating the ~500 megs a movie if the quality improves over what I have been doing already.

That said, my very quick "listening test" with eac3 @ 640 sounded great. If 384 kbps sounds better than normal ac3, cool, but also the paragraph above. :-)

[klogg416]

@khaosx
Today I have been averaging a little over 50 fps, and only encode 1 file at a time. I have never done (maybe once very early on?) a full library re-encode. My current library is a mess of encodes with different versions of transcode-video, changing philosophies (mine and Don's), and evolving technical preference and expectations. And I have started to make some of the full fat source files available without transcoding; since I was storing them anyway, not having 2 copies saved me space for movies that I know will only ever be watched on the "big TV".

The exercise today was driven by a long process of seeing significant improvements and knowing the time to re-encode was approaching. This morning's release felt like a good time. I'll probably do 20-30 movies and see how I feel, started with kids ones which get a lot of iPad time, will work up to some of my movies last.

@donmelton is a masochist, I can't speak to his monthly acrobatics.

[damorrison]

I need to do some tests with eac3 as I know my Sonos doesn’t do anything other than ac3. However, I’ve read that it’s possible my Samsung tv might downmix eac3 to ac3 automatically if I ask it which would be great. It might also just convert it to PCM though. I’ve also read that eac3 is backward compatible to ac3 but I’m less inclined to believe that as I don’t understand how it could be. Also, Is there loss in sound quality going from a 5.1 ac3 to a 5.1 eac3 as that’s what my whole library is in at the moment, and I won’t be reripping anything anytime soon. I’ll have to run some tests in an eac3 source to see what my Sonos does with it, but I’m away until the end of the week

On Sun, 10 Mar 2019 at 23:26, Kyle ***@***.***> wrote: Huh, so it is. I am not going to lie to you, continuing to add the same 10% more data for even better eac3 is totally fine with me. Pretty much all my source files are FLAC versions of some HD surround encode, and the idea of better eac3 for the same price I have been paying all along sits well. It wasn't so long ago that I was just using --copy-audio and adding 50% to the file size... :-| Similar to how when you find an improved way to squeeze more quality out of the video encode at the same target bitrate, you keep the bitrate the same and take the quality instead of aiming for a the old quality at a lower rate, I am not sweating the ~500 megs a movie if the quality improves over what I have been doing already. That said, my very quick "listening test" with eac3 @ 640 sounded great. If 384 kbps sounds better than normal ac3, cool, but also the paragraph above. :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#270 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYJDfDLZy0Zb5To3uZMF_yu3XgY2nwpks5vVZSegaJpZM4bngRh> .

-- Kind regards, Dave

[klogg416]

@damorrison @khaosx

as that’s what my whole library is in at the moment, and I won’t be reripping anything anytime soon.

I definitely did sit down once and completely re-rip every single movie because I hadn't follow the readme and ripped to FLAC the first time. And it was limiting my options. So I don't always re-encode, but occasionally I have to correct and touch a lot of plastic discs.

[lisamelton]

@khaosx Yeah, just add --ac3-encoder eac3 --ac3-bitrate 384 to your command line. I should have mentioned that in the proposal. D'oh! Sorry about that.

Right now I only have 730 movies and TV episodes that I (re-)transcode because I'm the process of re-ripping the other half of my library to get lossless audio. I'm sure it'll easily be over 1,000 titles soon. :)

I use --avbr --quick so the average speed of my transcoding is about 60 FPS (and between 45 to 75 FPS) on my five year-old iMac. So I can easily get 10-15 titles done while I sleep.

@klogg416 Congratulations! Your audio still sounds great. :) Seriously, you should try a few experiments at 384 Kbps to see if you can hear the difference. Noisy "superhero" movies work well as test subjects.

My library is currently a mix, too. But eventually it gets homogenized to a single method.

And then I start re-transcoding everything again. :)

@donmelton is a masochist, I can't speak to his monthly acrobatics.

So freakin' true, my friend. :)

[lisamelton]

@damorrison If your ripped movies already contain AC-3 (rather than lossless) surround audio tracks, then I would just copy them to your transcoded files. That's the default behavior of transcode-video anyway and what I do.

Supposedly, DD+ can be easily converted/transcoded to AC-3, but it's not done like taking the DTS core from a DTS-HD audio track. It really does have to be transcoded, but, again supposedly, there's less "loss" moving from DD+ to AC-3 than from other formats.

Let me know what you find out about your Sonos and your Samsung TV!

[klogg416]

@damorrison
One thing to check with your Samsung TV is if surround sound is passed to the Sonos at all, if that is important to you. Both of my Samsung's will take a surround signal over HDMI and pass 2.0 stereo sound out of the optical SPDIF port to the receiver.

From the manual:

• The receiver will work when you have properly connected the optical in jack of the receiver to the DIGITAL AUDIO OUT (OPTICAL) jack of the TV.
• When the source is a digital component such as a DVD and is connected to the TV via HDMI, only 2 channel sound will be heard from the receiver.

[khaosx]

OK, I feel a little better then. :)

I started last July-ish re-ripping and encoding the entire library of movies. I don't particularly care about TV shows being in uniform format (with the exception of Doctor Who, The Walking Dead, Game of thrones, and my collection of The Three Stooges), so I've never done a full rerip there. Prior to that, I spent 2 years with just raw mkv rips on the server...watching as 50TB dropped to 3TB free, and that's when I came back into the fold with Don.

By the way... anyone who is re-ripping. For the love of all that's holy, grab the subs. You may not need them now, but you will eventually! I also store every single rip on portable USB drives that get stored in my safe. I will NOT be re-ripping again, ever.

@donmelton I crossed the 1000 movie mark last Wednesday with Kurosawa's Seven Samurai. I didn't plan it, but it happened to line up nicely.

Meanwhile, back at the point: Don, I'm going to do some test encodes tonight and an A/B test tomorrow. I'll withhold comment until then, but I suspect that it's going to be a thumbs up from me.

[klogg416]

@khaosx I am just going to leave this here. Recommended.

[khaosx]

@klogg416 Thanks man! I look forward to watching it after I finally get the kids down. Stupid time change.

[lisamelton]

@khaosx Oh yes, grab the subtitles when you rip!

Ripping over 1,000 titles means you definitely have some kind of evil habit now. :)

And thanks for testing! I look forward to your opinion!

@klogg416 That's an awesome video! I'll be watching after dinner tonight. Thanks!

[khaosx]

Ripping over 1,000 titles means you definitely have some kind of evil habit now. :)

It's been there for a while, man. I started this nonsense when you still had the whole thing in BASH because Andy and Rene made you their pick of the week on Macbreak Weekly. It's not at all a stretch to say that you are the only reason I can do more than Hello World in BASH :)

[lisamelton]

@khaosx Oh god. I've corrupted yet another soul. :)

[klogg416]

I started this nonsense when you still had the whole thing in BASH

Same, but it was Vector 22 with Rene. Still BASH though.

[khaosx]

One of us...one of us...one of us...

[klogg416]

@khaosx @donmelton

On the off chance that either of you hasn't burned through the entire Every Frame a Painting channel, twice, and you should, then I have one more piece of homework to assign. Jackie Chan - How to Do Action Comedy. It will ruin you on modern action movies, but totally worth it.

[lisamelton]

@klogg416 @khaosx The funny thing is that --avbr is actually me "resurrecting" that original ratecontrol system I described in that podcast with Rene. :)

[lisamelton]

@klogg416 No, I haven't seen everything on that channel. And that's great! Thanks, again! More after dinner video time tonight. :)

[klogg416]

@donmelton

The funny thing is that --avbr is actually me "resurrecting" that original ratecontrol system I described in that podcast with Rene. :)

Now I need to decide if I am going to watch another movie tonight, do the nostalgia podcast trip, or A/B test audio. It definitely isn't going to be A/B test, but lists should always have 3 elements...

[khaosx]

@klogg416 If you want the whole script, I'll DM you the gist address for it. Not going to pollute Don's issues list with it (we really need that wiki!), but you might find some useful tidbits. I'm khaosx in your twitter followers.

[lisamelton]

@khaosx @klogg416 Not only do we really need that Wiki, but I was thinking a Slack or Discord channel would be great. Which would you prefer and I can set one up for all of us this week?

[khaosx]

@donmelton I vote slack, but I'm ok with either.

This is your way of saying "Khaosx, you talk too damn much", isn't it?

[lisamelton]

@khaosx LOL! No, it's because I talk too damn much. :)

[klogg416]

@khaosx followed.

3 followers (and two who aren’t bots!), look at me showing off.

[lisamelton]

@khaosx @khaosx I've already followed both of you on Twitter, right? If not, I can rectify that now.

[klogg416]

I don't like using small, medium and large because small would be larger than medium and the same size as large. That doesn't seem right to me.

Fair and right. That distinction is what put me down the metaphor path, but I completely agree that it is too abstract. I am naming a target without explaining it. No good.

Which makes me think we should go with @samhutchins 's plan and not add API but instead just document it better.

This is exactly what my alternate approach is attempting. No changes to the commands, set the default at eac3 384 Kbps, and then explain options and why those options in the readme. With a table. “AC3 for DVD quality and maximum compatibility, EAC3-DD+ 384 for similar quality in less space, eac3-DD+ 640 Kbps to goose the quality because you want the booms and you have the drives.”

[lisamelton]

@klogg416 OK, here's my stab at explaining the proposed behavior for 5.1 channel surround audio, i.e. after the implementation of this proposal...

Options	Format	Bitrate	Purpose
(none)	DD+	384	Small but still high quality
--ac3-encoder ac3	AC-3	640	Large but compatible with legacy devices
--ac3-bitrate 640	DD+	640	Large but even higher quality

Simpler?

[klogg416]

For the record, I swung around to @samhutchins plan, I think we change nothing but the default and just detail why a person would choose a less or greater option.

[lisamelton]

@klogg416 Agreed, which is what my new chart is trying to do. But, hey, it's a first attempt. And I couldn't have done it without looking at yours first.

[klogg416]

@donmelton

here's my stab at explaining the proposed behavior

I like it, especially the “(none)” indicating default, the only thing I would challenge is describing either as “large.” They aren’t large, they are conservative, we are just debating the relative margins of conservative. TrueHD is large. FLAC is large. AC3 is... not as efficient as a modern option. DD+ 640 is not large either, but you get more out of it.

I think your description shouldn’t deter people from any of the 3 viable options, rather it should explain the relative difference as upside: compatibility, tiny, boom.

[klogg416]

@donmelton I always miss the first line when you @ me, I don’t know why I skip to the meat of the post, but I only see the first line when I go to clear my emails. Thanks, I spent time on the tables, they aren’t hard really but much harder to revise in markdown than in Excel where it is easy to move columns and restructure. I think a weekend project is going to be a script that takes formatted Excel tables and dumps them into .md.

Work like the pros, output with polish. You will know I failed when you get screen shots of Excel tables. 😏

[khaosx]

Sorry to be so late to the conversation, life got in the way last night.

As long as we adequately explain WHY you would use a particular setting, I don't think it really matters to anyone but us hard-core pedants what we call the settings.

That said, I'd personally push for lining up output with the three masts with something like a --tune setting.

Option	Format	BitRate	Purpose
default	DD+	640	Think of it as --tune=balance
--tune=portability	AC3	640	Best compromise for legacy devices
--tune=size	DD+	384	Best compromise for size
--tune=fidelity	Copy Audio	Original	For the true animals among us.

Going in that direction allows us to make better informed decisions when evaluating new defaults or features. We can even retune the rest of the output variables like resolution, whether to use --avbr or the one special trick.

It's as close as I would like to get to having "presets".

[khaosx]

And before the questions come, yes, I know I just proposed changing the default to 640Kbps DD+. I tend to agree with @rhapsodians about that.

By adopting the stated goals of the project (portability, size, fidelity) and making them the overriding philosophy, we have to accept that every choice is a compromise between the three. Defaults should be the best compromise between the three. Any additional tuning to those defaults should represent a weighted balance, e.g. smaller file size, sacrificing a small bit of portability and fidelity.

The folks who are using this tool (which I plan to refer to from now on as VTP) aren't typically going to be your garden variety users. I think that what really makes it sticky is the ability to make informed decisions about your output, but not the necessity of being an expert. Let's face it, a lot of us started out with a very small command, and added in parts as we found itches that needed to be scratched. Even if we don't incorporate that verbiage, it's still a good way to put our decisions into perspective, and a great way of explaining the choice to users, both expert and beginner.

[klogg416]

@khaosx there is a lot to like in the last two comments:

--tune feels like a good representation of what is happening behind the scenes. And the descriptions are in line with my goal of explaining the reason why to use a option rather than focusing on the downside of it.

I still like the idea of 640 Kbps being the default. Especially in a world where we move away from including a second stereo track by default since there is already savings realized there.

I challenge including the --copy-audio as one of the --tune options since it is decidedly not tuning. It is the anti tune. And I am going to preemptively channel @samhutchins to raise concerns about changing APIs and continuity and all the smart things that let less engaged users update and not break their workflows. I love me some --copy-audio, it should just remain its own thing outside of the transcoding audio options.

Long live 640 Kbps!

[khaosx]

That's fair, @klogg416. I included it as an option to give a weighted-balance option for major fidelity. Just think of me as Thanos, with a less purple chin and a less sociopathic agenda!

Especially in a world where we move away from including a second stereo track by default since there is already savings realized there.

More than that. It actually justifies making --audio-width all=surround the default.I hand't thought of it that way, but it really does, if you think it through.

[samhutchins]

I really don't like the idea of adding these preset-like options. I think they inflate the API, and potentially make things confusing. Especially because these options are macros around the existing audio options.

---

To Don's original proposal: any time the defaults are changed it's always been to increase quality, decrease size (while maintaining quality), or both. I think this change fits right into the goals of the project, and the precedent set by earlier changes.

[dkoenig01]

This has been a lot to catch up with after a sabbatical! Count me in the camp that would lean toward 640 DD+ as I’m willing to keep the same efficiency as AC3 but take advantage of the higher fidelity, but that’s just my preference and I think 384 as default fits with the philosophy of the project. I’d still have to run my own tests, and my Sonos soundbar in the bedroom certainly won’t like it regardless (shaking fist in air) but between the ATV and Samsung I’m sure the downconversion to DD will suffice. I don’t think —tune is explicit enough in being related to audio only, so —audio-tune or —atune may be more appropriate. Piggybacking off previous suggestions, I’d offer the following as options (sorry no fancy tables here): default - DD+ 384 legacy - AC3 640 fidelity - DD+ 640

[lisamelton]

@dkoenig01 Thanks for the feedback! And welcome back, too! I would have responded to @klogg416, @khaosx and @samhutchins earlier but we actually discussed it our new Slack workspace. Let me know if you want an invitation.

[lisamelton]

@dkoenig01 BTW, I really like describing the purpose of using DD+ at 640 Kbps as wanting "higher fidelity." Nice.

[lisamelton]

@klogg416, @khaosx and @samhutchins To re-iterate what I said earlier on Slack...

I'm gonna have to go with Sam on this one. Let's just change the default and not add any shortcuts to the API. At least not at this time. Let's find out if we can explain the options to users without doing that first. Here's my second pass on that explanation with feedback from Kyle (on not mentioning sizes) and @dkoenig01 (on wording):

Options	Format	Bitrate	Purpose
(none)	DD+	384	Default behavior
--ac3-encoder ac3	AC-3	640	Compatibility with legacy devices
--ac3-bitrate 640	DD+	640	Higher fidelity

Is this good enough?

[klogg416]

@donmelton

Is this good enough?

I think it is. Since DD+ is the default across the board, I think that solves some of what we were trying to surface, or at least what I was. I like that no option means DD+, I like that it means getting to 640 Kbps is a single option because eac3 is assumed.

I question if --ac3-bitrate is clear, would people understand that that option impacts the bitrate of either eac3 by default, or ac3 if specified? I am pretty sure I would miss that and incorrectly assume it only impacts the old format. Would --audio-bitrate be more clear?

[lisamelton]

@klogg416 Thanks and excellent question! And I've been thinking about this over the last few days. I just didn't want to mention it for fear of muddying the waters. :)

But I don't think we should change the option name to --audio-bitrate. Because that would imply it also affected the stereo and not just the surround bitrate. We could of course prefix the argument with stereo= or surround= but, as @samhutchins advised me just last week (I think), that could seem a bit complex for users.

And if we change the option to --surround-bitrate then we have the question of whether that affects AAC format because we just added the ability to do --audio-format surround=aac, mostly for Android users of course.

So it's complicated. :)

My advice would be to not change the option name in the short term. But definitely consider it in the near future.

Thoughts, all?

[klogg416]

@donmelton

It is complicated, I wasn't thinking of all the AAC stuff.

    --ac3-bitrate 384|448|640|768|1536
                    set surround audio bitrate for both ac3 and eac3, collectively known as AC-3
                      (default for ac3: 640; default for eac3: 384)

?

[lisamelton]

@klogg416 OK, I can see mentioning both formats in that --help line. I'll work on something that will fit in less than an 80-character width. Stay tuned...

[vr8hub]

@donmelton <https://github.com/donmelton> Uggh. If someone still keeps their terminal at 80 characters they deserve for it to wrap. Are you still watching videos in 640x480? Don't be fooled by Captain Marvel, it ain't 1995. (Although I wasn't still using 80-characters then, either.) Give that monospaced font some room to breathe.

[lisamelton]

@vr8hub I actually like the limitation because it forces us to be thoughtful and succinct. Also, the wrapping text in the very few tools which I could find that do such a thing (e.g. gcc) look... just terrible.

We should always strive for the best typography possible. Even in the console. :)

[vr8hub]

@donmelton <https://github.com/donmelton> Of course we should always strive for the best typography possible. I said nothing to the contrary. I said we shouldn't be shackling our typography with a 40-year old limitation, any more than we should be generating videos that fit in 640x480. You don't need to find tools to "do such a thing". You should assume 132 characters. If someone is using less than that, they're used to wrapping text. Just like people who still use 640x480 are used to not seeing everything on the screen at the same time. Both are ugly, but that's the price for living in 1982.

[lisamelton]

Here's the patch which implements this proposal:

diff --git a/bin/transcode-video b/bin/transcode-video
index 6b19b18..39c286d 100755
--- a/bin/transcode-video
+++ b/bin/transcode-video
@@ -143,9 +143,10 @@ Audio options:
                     copy rather than transcode AC-3 stereo or mono audio tracks
                       even when the current stereo format is AAC
     --ac3-encoder ac3|eac3
-                    set AC-3 audio encoder (default: ac3)
+                    set AC-3 audio encoder (default: eac3)
     --ac3-bitrate 384|448|640|768|1536
-                    set AC-3 surround audio bitrate (default: 640)
+                    set AC-3 surround audio bitrate
+                      (default for ac3: 640; default for eac3: 384)
     --pass-ac3-bitrate 384|448|640|768|1536
                     set AC-3 surround pass-through bitrate (default: 640)
     --copy-audio TRACK|all
@@ -263,8 +264,8 @@ HERE
       @surround_format            = 'ac3'
       @stereo_format              = 'aac'
       @keep_ac3_stereo            = false
-      @ac3_encoder                = 'ac3'
-      @ac3_bitrate                = 640
+      @ac3_encoder                = 'eac3'
+      @ac3_bitrate                = nil
       @pass_ac3_bitrate           = 640
       @copy_audio                 = []
       @copy_audio_name            = []
@@ -833,6 +834,7 @@ HERE
     end
 
     def configure
+      @ac3_bitrate ||= @ac3_encoder == 'eac3' ? 384 : 640
       @pass_ac3_bitrate = @ac3_bitrate if @pass_ac3_bitrate < @ac3_bitrate
       @extra_audio.uniq!
       @copy_audio.uniq!

[jodyfanning]

A couple of question related to this. I just started on a ripping binge a few weeks ago and just today noticed this discussion. I don't have the space to keep the raw rips, so I'm only keeping the encodes (I still have the discs). And I have been keeping the existing default which is AAC + AC3, mostly for compatibility.

So two things, how far back DD+ basically goes? My amp is 10 years old, and it doesn't mention DD+ at all in the manual, only DD Ex. I also didn't see anyone mention how a PS4 deals with DD+?

Other thing is a more general thing. If I have an original AC3 track on the disc is it better to just pass that through or re-encode a new version from the lossless tracks (TrueHD, etc)? I would assume that in the switch to DD+ re-encoding would be the only way to go? With AC3 I assumed the original disc encoding to AC3 would be better than whatever Handbrake would do, or is that a false assumption?

[lisamelton]

@jodyfanning Sorry I took so long to respond. I've been AFK for the last few hours. ...

These are great questions!

If the documentation for your amp doesn't mention DD+ or Enhanced AC-3 support then I would not recommend using the format. Of course, you could try creating a single video using it and see if you have any playback issues.

The AC-3 encoder used by HandBrake is very good and well-tested. The DD+ encoder is new, not fully featured and not tested quite as well. So I think it's safe to continue transcoding your lossless audio to AC-3 format. But because you're not keeping your original rips, I would not recommend doing that with DD+.

You can certainly copy the appropriate AC-3 track from your rips now but I doubt you will notice much difference, if any, between the transcoded audio from HandBrake.

I hope that helps!

[jodyfanning]

I think 3 hours response time is pretty fine for me :-). Thanks for the info.

I usually passthrough the AC3 directly for simplicity even if there is a lossless track, but I also noticed that the AC3 track is very often lower bitrate than the max 640. Sometimes around 400 or less. So I should be more picky about which ones I re-encode and which I pass through. I am not that much concerned about the absolute size, more compatibility. But i would also like to keep whatever quality is possible. I'm not planning to do this again any time soon!

Will these changes affect the previous dual audio track AAC+AC3? And would there need to be anything special done to preserve that behaviour?

[samhutchins]

If and and when Don lands this change, you'll need to add --ac3-encoder ac3 to your command. Other than that, nothing else changes for you to preserve the current behaviour

[lisamelton]

@jodyfanning As usual, @samhutchins is completely correct. Thanks, Sam!

[ctismer]

@donmelton Hi Don! I'm a new user of your video transcoding system and very pleased with it. My video library is 20 TB huge and running out of space, because I always was too lazy/shy to convert my videos. When I found your scripts, I was very happy to get rid of the burden to decide which parameters to use :-)
I will see if I can help on this topic, too.
See you -- Chris

[lisamelton]

@ctismer I'm glad you like it and find it useful, sir! And, yes, feel free to comment.