0

I am using ffmpeg to convert AAC audio from TS (Transport Stream) container format to M4A container format. My intention is (or was) to perform this without re-encoding. However there seem to be two ways of getting ffmpeg to do this, producing different results.

The source file, with [.ts] extension, is VBR, overall 162 kb/s, size 8.5 MB

A "straight" use of... ffmpeg -i infile.ts outputfile.m4a ..produced an [.m4a] file of AAC with VBR, 162 kb/s, size 7.1 MB I assume this reduction in size is due to the TS format's transmission-error tolerance data having been "filtered out".

However when I included parameter [-codec copy]... ffmpeg -i infile.ts -codec copy outfile.m4a ...this produced an [.m4a] file of AAC with CBR, 93.3 kb/s, size 5.1 MB I guess this implies the audio has been re-encoded, from VBR to CBR, presumably losing some audio data in re- (lossy) compression (unless such BR conversion is cleverer than that).

Have I interpreted the above correctly? Is it the case that the product of the "straight" (no -codec parameter) ffmpeg run is likely to have better (or exactly) preserved the quality of the original? Or is the CBR product of the second ffmpeg run likely to have the same (or indistinguishably different) audio quality?

Improve this question
7
  • Comparing the spectrum plots for all three copies (original TS, straight-converted, parameter-converted) showed no difference. To do this, I plotted each in iZotope RX, screen-grabbed the spectrum display window, differenced them as image layers in Gimp (graphical editing app).
    – esp
    Commented Apr 19, 2022 at 15:41
  • To try to hear any difference between the waveforms themselves, I imported the two conversions into REAPER (DAW), inverted the phase of one of them, and played. Some top-end/treble was apparent. I wonder if, given the result of my previous comment, this could be explained by some phase shifting - that may (hypothetically) have occurred either during the conversion (by ffmpeg) or in the way REAPER handled these two files (one VBR, the other CBR). Thereby: same frequencies but non-matching phases.
    – esp
    Commented Apr 19, 2022 at 15:50
  • In REAPER, I also tried altering the relative phase (of one track) via (JS) Phase Rotator (FX plugin). Minimum difference was confirmed to be at 180 degrees - and audible result was consistent with that from phase/polarity inversion of the track.
    – esp
    Commented Apr 19, 2022 at 16:01
  • I did some processing rate/time experiments on a larger file, ~500 MB. The "straight" process was reported as ~100x real-time and took ~4 minutes. The "codec copy" process was reported as ~4000x real-time and took only a few seconds.
    – esp
    Commented Apr 19, 2022 at 16:42
  • Based on the rate/time experiments, it would seem that the "codec copy" process was doing less work. Surprising in that case that the end-result of it was a CBR encoding rather than a VBR one.
    – esp
    Commented Apr 19, 2022 at 16:44

1 Answer 1

Reset to default
1

A "straight" use of... ffmpeg -i infile.ts outputfile.m4a, i.e. omitting -codec copy, results in the (encoded) media first being decoded then being (re-) encoded (assuming ffmpeg's default settings for the target file/encoding-type, e.g. m4a).

To ensure that only rewrapping occurs (no decode/re-encode), the -codec copy or equivalently -c copy (or separate equivalents for audio and video, as per one's requirements) is essential.

The same question was asked (and answered) on StackOverflow

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .