View Single Post
Old 13th November 2018, 05:56   #30  |  Link
Trench
Registered User
 
Join Date: Sep 2015
Posts: 16
A couple observations I had from 1.7.0.6, which today I've been able to determine still exist in 1.9.0.0 x64:

1. When trying to use non-default options for the ffmpeg "dynaudnorm" process, the options are incorrectly constructed in the ffmpeg command line. For example if you de-select "Enable channel coupling", the command line options are constructed as:

Code:
ffmpeg -q:a 4 -af dynaudnorm n=false
instead of being correctly constructed as:

Code:
ffmpeg -q:a 4 -af dynaudnorm=n=false
Per ffmpeg filtering guide documentation, additional options would need to be colon-separated, such as this example of adding "r=0.95" to the previous command line:

Code:
ffmpeg -q:a 4 -af dynaudnorm=n=false:r=0.95

2. Specifying a non-default RMS of "0.95" in the dynaudnorm options is accepted by the GUI, and is added to the command line (not withstanding the incorrect construction issue already described). But when you then re-enter the GUI of dynaudnorm options, it shows the current RMS as being "1.0", instead of the "0.95" that was selected and is still visible within the command line. (Screen shot attached, once available.)


3. I rip one of my Blu-Rays, and have eac3to extract my preferred 5.1+ audio file to FLAC. In making an MP4 of this video, I now want to re-encode this FLAC audio "two ways" into my resulting MP4 container: Once to AAC while down-mixing to stereo for when I'm playing on my crappy TVs (so that the audio is "loud enough"), and again to AAC while keeping the original 5.1/6.1/7.1 the Blu-Ray contained (in case I don't have crappy TVs in the future and want to select playback of a higher-quality audio track).

But StaxRip defies doing this, saying "The first and second audio source files or streams are identical", apparently in reference to the having the same FLAC file selected as the input for the two different output encodings. (Screen shot attached, once available.)

It's not that "it literally cannot be done"; StaxRip seems to just be complaining about the file name being the same for the input in both sources, even though the resulting ACC re-encodings into the MP4 container will be different. If I manually duplicate and create a separate input FLAC file which is simply a copy the first FLAC file, the "two different encodings of the same input FLAC file" (now with two different input file names) is allowed.

Rather than StaxRip saying "you can't get there from here" and requiring manual intervention, it seems like StaxRip could at minimum be performing the same thing I'm having to do manually: Simply duplicate the FLAC (or whatever the "duplicate" source file is) to a temporary file, and use it as input for the second encoding.

Hmm... is this actually just a temp file name management issue? e.g. Is StaxRip's complaint really based on the fact that the temp file name(s) generated for these re-encoding attempts will be identical? (i.e. same FLAC file base name, same export track ID number in file name, etc.) Such that it could really be solved by just appending a "target track ID" to the temp file names, representing what track number it will be in the resulting MP4 file. Thereby preventing the two separate re-encoding processes of the same input file from stepping on each other's temp file names.

Thanks for considering.

EDIT: Can now confirm all three issues remain unchanged in 2.0.0.0, for what it's worth.
Attached Images
  

Last edited by Trench; 14th November 2018 at 18:46. Reason: Confirmed 2.0.0.0 testing
Trench is offline