4 Replies Latest reply on Jun 7, 2012 4:15 AM by Steven Pribilinskiy

    Normalizing Audio Gain is not precise anymore (CS6)

    Steven Pribilinskiy Level 1

      Precision of Audio normalization is dropped in CS6. Here is a sample video:

       

      Now razor cut should be performed minus -10 frames before each volume change in order to obtain correct decibels with the Clip's Audio Normalization feature.

       

      This happens with mp3 files, everything is still fine with wav/aiff.

      I can't convert the mp3 with neither Media Encoder nor Premiere Pro. It's a 10 h long external recording.

      I have opened it with Audition and saved as 32-bit wave file, but Premiere Pro doesn't recognize such long files (15 Gb).

        • 1. Re: Normalizing Audio Gain is not precise anymore (CS6)
          Jim_Simon Level 8

          Premiere Pro doesn't recognize such long files (15 Gb).

           

          It's probably not the length, but the 32 bit depth.  Encode it to 16bit, 48kHz wav.  That should work fine.

          • 2. Re: Normalizing Audio Gain is not precise anymore (CS6)
            Toy Ray Gun Level 1

            .wav files use a 32 bit file header (not to be confused with 32 bit audio precision) and can only be up to 4GB in size. You would need to cut the .mp3 into smaller pieces and save out a number of .wav files.

            The problem you are having with the normalization function is probably because you are using such a long compressed file.

            • 3. Re: Normalizing Audio Gain is not precise anymore (CS6)
              Steven Pribilinskiy Level 1

              This bug is definitely not depends on file size, see new sample video:

               

              Somewhy Audition trims leading audio of the converted mp3.

              export.jpg

               

               

              Question: why would be needed to perform these additional cutting+converting steps when Premiere performs Conforming operation on every Compressed Audio - it converts each audio stream to Project Audio Format: 48000 Hz - 32 bit floating point - Stereo. This step also takes time and drive space (approx. 14 Gb 32-bit cfa per 1 Gb 320 kbps 16-bit mp3). Will send a Bug Report wishform.

               

              Hopefully Todd Kopriva or Wil Renczes or whoever from the "large beta-testing group" will ask for an mp3 sample

               

              Feature Request/Bug Report Form

                ******BUG******

              Concise problem statement:Normalizing Audio Gain of an mp3

              Steps to reproduce bug:

              1.Import some mp3 with voice speech

              2.Normalize Audio Gain

              Results:Incorrect normalization

              Expected results:Correct normalization as before in CS5.5 and older

              Link: https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

              • 4. Re: Normalizing Audio Gain is not precise anymore (CS6)
                Steven Pribilinskiy Level 1

                Solved!

                After creating a sequence based on the 110910_0024.mp3 (by dragging it to the New Sequence) icon - Normalization is correct, the issue is gone.

                So why is this magic behaviour?

                It's certainly not because of the Long 10h+ Audio Files.

                It's because in the Main Video Sequence Settings the Audio Sample Rate was set to 48000 Hz (Video Files Sample Rate) and the external Compressed Audio mp3 Sample Rate from a ZoomH1 Audio Recorder was 44100.

                 

                Solution is to Cut/Paste to another sequence with the necessary Sample Rate or convert the mp3 file to another mp3 with Video's Sample Rate if you mixing them and of course set the recorder to 48000 for future projects.

                It's good that I have only 5 more projects with external audio set to 44 kHz.

                 

                This bug is introduced in CS6.

                It's interesting in what timeframes it will be fixed, if ever (because nobody experience this). The link to this discussion is sent with the Bug Report. All the details are here.