Does encoding in Handbrake without Audio make the encode faster?

[focuspuller]

I'm encoding something that's going to take a long time.

Does encoding in Handbrake without Audio make the encode faster?

[abolibibelot]

Usually audio encoding is very light in CPU power requirements, compared with video encoding, so it shouldn't affect the total encoding speed significantly. You could run a test with a 5min. sample to verify this. Although one justification of encoding audio separately would be to benefit from a better quality encoder than the ones implemented with Handbrake, qaac for instance. So you could first encode the audio with qaac, then encode the video and select the already encoded audio to be muxed directly in “pass-through” mode (no re-encoding).
Why is it going to take a long time, because it's a long video, a slow computer, or you are applying some slow filters ?

[KarMa]

Skipping audio won't speed up the process much more than a few minutes, on a 2hr video.

[focuspuller]

It's a four hour video in this case. Thanks guys!

[focuspuller]

Usually audio encoding is very light in CPU power requirements, compared with video encoding, so it shouldn't affect the total encoding speed significantly. You could run a test with a 5min. sample to verify this. Although one justification of encoding audio separately would be to benefit from a better quality encoder than the ones implemented with Handbrake, qaac for instance. So you could first encode the audio with qaac, then encode the video and select the already encoded audio to be muxed directly in “pass-through” mode (no re-encoding).
Why is it going to take a long time, because it's a long video, a slow computer, or you are applying some slow filters ?

One scene has filters. But long video.

[abolibibelot]

If it's too long to do in one operation you could encode it in several parts, and then append them together with MKVToolNix. In this case, preferably choose the cut points at distinct boundaries like a fade to black, and use the --stitchable optional switch in the x264 command.

--stitchable            Don't optimize headers based on video content
                        Ensures ability to recombine a segmented encode

[somespirit]

in my opinion first encode video then audio and after that mux both using mkv or mp4 container

[abolibibelot]

in my opinion first encode video then audio and after that mux both using mkv or mp4 container

But as it's been said above this won't help much as audio encoding time will be about 1% of the total...

[somespirit]

if source is on hard drive then you will have two readings from hard disk, one for video encoding and one for audio encoding and that will do heavy load to disk (if you use SSD no problem), imagine you encode source with 10-15Mbit video bitrate and source is about 10-15GBytes

also when you encode both video and audio (at same time) multithread (CPU) scaling tasks on CPU will be not so good as if it they are separately .......

[abolibibelot]

if source is on hard drive then you will have two readings from hard disk, one for video encoding and one for audio encoding and that will do heavy load to disk (if you use SSD no problem), imagine you encode source with 10-15Mbit video bitrate and source is about 10-15GBytes
also when you encode both video and audio (at same time) multithread (CPU) scaling tasks on CPU will be not so good as if it they are separately .......

That would be negligible IMHO... A modern 2TB+ HDD has a reading speed of at least 150 megabytes per second ; 10-15 megabits per second is actually 1.25-1.875 megabytes per second ; and unless using very fast settings on a very fast computer, x264 encoding is usually done at a fraction of real-time playback, so the actual throughput is actually less than that ; and lossy audio adds only a few kilobytes per second.

[sneaker]

if source is on hard drive then you will have two readings from hard disk, one for video encoding and one for audio encoding and that will do heavy load to disk (if you use SSD no problem), imagine you encode source with 10-15Mbit video bitrate and source is about 10-15GBytes

Usually HandBrake will be used to read from interleaved files. Doing video and audio together should be faster than separating the jobs. If you do it separately you will need to write the video data twice. Once when enconding and then again when muxing with audio.

also when you encode both video and audio (at same time) multithread (CPU) scaling tasks on CPU will be not so good as if it they are separately .......

I'd say doing multiple tasks on a multi-core CPU is a good way to increase the effective CPU utilization. Or does HandBrake not separate video and audio encoding into different threads?