Closed anderslundstedt closed 4 days ago
From the README:
The default audio encoding method is uncompressed PCM (pcm_s16le) to avoid introducing compression artifacts. This will result in a much higher bitrate than you might want, for example if your input files are MP3s.
Some containers (like MP4) also cannot handle PCM audio. If you want to use such containers and/or keep the file size down, use -c:a and specify an audio codec (e.g., -c:a aac for ffmpeg's built-in AAC encoder).
Does this help?
See also new FAQ entry: 6a3287682eeac7cc48e86cce34ec35db8a993af5
From the README:
The default audio encoding method is uncompressed PCM (pcm_s16le) to avoid introducing compression artifacts. This will result in a much higher bitrate than you might want, for example if your input files are MP3s.
Some containers (like MP4) also cannot handle PCM audio. If you want to use such containers and/or keep the file size down, use -c:a and specify an audio codec (e.g., -c:a aac for ffmpeg's built-in AAC encoder).
Does this help?
Indeed it does! What puzzled me was that the metadata from ffprobe
was incorrect, which extracting the audio proved. Perhaps this incorrect metadata should be considered a bug?
By the way, this probably just shows my ignorance of how audio codecs works but the non-metadata implies an even larger increase in audio stream size:
4608kb/s × ~2h ≈ 32GiB
The metadata gets carried over from the input. Actually, I've gone to great lengths to preserve all metadata, as that was a common request by users. What specific metadata are you referring to though?
As for file size, you forgot that the rate is in bits, so: 4608 kBit/s = 4.6 MBit/s, so that's 4.6 MBit ⨉ 3600 s ⨉ 2 h = 33120 MBit = 33.12 GBit = 4.14 GB for your entire file. (The audio stream only, obviously. The rest is video.)
The metadata gets carried over from the input. Actually, I've gone to great lengths to preserve all metadata, as that was a common request by users. What specific metadata are you referring to though?
At the very least, preserving NUMBER_OF_BYTES
in the audio stream metadata for the normalized output seems undesired?
Stream #0:1: Audio: pcm_s16le, 48000 Hz, 6 channels, s16, 4608 kb/s
Metadata:
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
BPS : 238470
NUMBER_OF_FRAMES: 522081
NUMBER_OF_BYTES : 214523891
_STATISTICS_WRITING_APP: mkvmerge v56.0.0 ('Strasbourg / St. Denis') 64-bit
_STATISTICS_WRITING_DATE_UTC: 2021-12-31 14:24:29
ENCODER : Lavc58.134.100
DURATION : 01:59:56.661000000
As for file size, you forgot that the rate is in bits, so: 4608 kBit/s = 4.6 MBit/s, so that's 4.6 MBit ⨉ 3600 s ⨉ 2 h = 33120 MBit = 33.12 GBit = 4.14 GB for your entire file. (The audio stream only, obviously. The rest is video.)
Yes, of course, thank you.
The metadata gets carried over from the input. Actually, I've gone to great lengths to preserve all metadata, as that was a common request by users. What specific metadata are you referring to though?
At the very least, preserving
NUMBER_OF_BYTES
in the audio stream metadata for the normalized output seems undesired?
True. These are non-standard and added by mkvmerge
. I am not sure how to deal with this easily, as there could be many such tags … maybe I'll find some time to address it.
I want to normalize a file
input.mkv
. I use the command:File sizes of
input.mkv
andrms_normalized_to_-10.mkv
, respectively:Is there a way to avoid this huge increase in file size?
Additional context
std_err.txt
from the command above:std_out.txt
from the command above:% ffprobe input.mkv
:% ffprobe rms_normalized_to_-10.mkv
: