The audio is not untouched; it is just not included in the output. Even though tools like MediaInfo, Handbrake, and MKVToolNix show audio and video streams separately, the truth is they're all mashed together into a single bitstream. If this was not the case, a player would have to read all the audio, hold it in memory, then read & display the video and time sync the audio it is holding in memory to the video. Instead the audio and video are multiplexed together. A multiplexer allows for multiple inputs like a video stream and several audio streams to share one single file. When a player plays the file, it demultiplexes the file back into individual bitstreams so the video decoder can decode the video and an audio decoder can decode the audio so they can be output at the same time.crazyg0od33 wrote: ↑Wed Jul 09, 2025 2:22 pmHonestly it's probably fine to do it that way, but it's not really much extra time on my computer, (maybe two minutes through mkvtoolnix), and some part of me just likes not having the audio touched by handbrake, and just using the fully raw audio track from the initial rip. Probably a weird way to go about it, I just like knowing the audio is untouched haha
Handbrake takes the input file, demuxes (demultiplexes) it, does whatever you tell it to do to the elementary streams (aka encodes the video however you say and encodes the audio however you say) then muxes (multiplexes) the appropriate streams back together. If you told Handbrake to just copy the main audio track from the source into the output, it would do it muxing it together with the encoded video it produced.
Muxing in the audio in a second step via MKVToolNix doesn't really hurt, but it doesn't really help either. To each their own.
