Skip to main content
A
alh97334218
Participant
June 4, 2018
Answered

Encoding differences between AME 17 and AME 18

  • June 4, 2018
  • 2 replies
  • 555 views

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

This topic has been closed for replies.
Correct answer Dave Merchant

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.

2 replies

A
alh97334218Author
Participant
June 15, 2018

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,

D
Dave MerchantCorrect answer
Legend
June 15, 2018

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.

D
Dave Merchant
Legend
June 4, 2018

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?

A
alh97334218Author
Participant
June 5, 2018

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

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices