Encoding differences between AME 17 and AME 18

[alh97334218]

Hello everyone,

I would like to talk to you about a weird and intriguing problem I encounter.

I'm actually a professional encoder using AME every day for work to upload videos on a platform.

Since the release of AME 12.1 version, I'm experiencing some issues in my uploads.

I'm using the same presets and parameters to encode my files, but the platform I'm using is not letting my files through.

Do you know if during the update between AME 2017 v11.1.1.35 and AME v12.1.0.171 a major change has been made, thus modifying the file surreptitiously.

Please, if anyone has come across the same issue let me know as I'm feeling a bit left out by Adobe Support; andd can't figure out what the issue could be

Thanks everyone

[Dave Merchant]

Basic information is required - what codecs in and out, is the source direct-linked or from a file, what is your "platform" expecting to get, and what if any are the differences shown between valid and invalid files when you pull the headers with MediaInfo?

[alh97334218]

We've noted a discrepancy between files produced by AME 2017 v11.1.1.35  and AME 2017 v12.1.0.171 with the same presets/parameters. This discrepancy appears in the Audio bitrate, the AME 2017 v11.1.1.35 produces films with an Audio "Bit rate" and the AME 2018 v12.1.0.171 produces films with a "Nominal bit rate". We do analyse our MP4 files using MediaInfo and the expected bit rate in our spec is (constant) 256kbps.

If a source file has a "Source duration" and "Source stream size" fields then AME will create "Nominal bit rate" in output file rather than "Bit rate" when AME v12.1.0 or v12.1.1 is used. Could you please tell me why's that? In other words, why wouldn't the file remain the same - i.e. the output file should remain in bit rate

[alh97334218]

Hello again everybody,

I thought I'd add some extra info I've come across that may help identify where the "bug" resides in their code .

Our experiments on a variety of files seem to indicate that where a source file has a "Source duration" and "Source stream size" fields, then AME will create a field called "Nominal bit rate" in an output file rather than one called "Bit rate" when AME v12.1.0 or v12.1.1 is used.

If a source file does not have "Source duration" and "Source stream size" fields, then AME will create a "Bit rate" field as expected in an output file when AME v12.1.0 or v12.1.1 is used.

I used MediaInfo to view the fields and their values from the video files and hope that someone will be able to help and advise on how to resolve this issue.

Many thanks,

[Dave Merchant · Accepted solution]

Seems that what you're talking about is solely a change in the XMP metadata, not in the stream data. Frankly, no broadcast validation filter should trust the metadata in anything.

In H.264/AAC "nominal" bit rate is technically the more correct terminology. Even with CBR mode selected, the AAC algorithm performs compression (e.g. duplicate removal on stream chunks), so the number of bits of audio data passing through the decoder at any one moment in time is not constant. CBR sets the mean bitrate target to a narrow range of values, but try encoding identical-length tracks of music vs silence, and see what it does to the file size.