Flac to mp3 conversion offsets sound by a few ms












0















When running this simple conversion command: ffmpeg -i fileA.flac fileB.mp3
, the mp3 output is offset by about 5 ms.



This does not happen if I try to convert to Vorbis/Ogg (i.e ffmpeg -i fileA.flac fileC.ogg)



Audacity screenshot:



Audacity screenshot showing offset



Any idea why this happens and how I can fix it?










share|improve this question





























    0















    When running this simple conversion command: ffmpeg -i fileA.flac fileB.mp3
    , the mp3 output is offset by about 5 ms.



    This does not happen if I try to convert to Vorbis/Ogg (i.e ffmpeg -i fileA.flac fileC.ogg)



    Audacity screenshot:



    Audacity screenshot showing offset



    Any idea why this happens and how I can fix it?










    share|improve this question



























      0












      0








      0








      When running this simple conversion command: ffmpeg -i fileA.flac fileB.mp3
      , the mp3 output is offset by about 5 ms.



      This does not happen if I try to convert to Vorbis/Ogg (i.e ffmpeg -i fileA.flac fileC.ogg)



      Audacity screenshot:



      Audacity screenshot showing offset



      Any idea why this happens and how I can fix it?










      share|improve this question
















      When running this simple conversion command: ffmpeg -i fileA.flac fileB.mp3
      , the mp3 output is offset by about 5 ms.



      This does not happen if I try to convert to Vorbis/Ogg (i.e ffmpeg -i fileA.flac fileC.ogg)



      Audacity screenshot:



      Audacity screenshot showing offset



      Any idea why this happens and how I can fix it?







      ffmpeg conversion mp3 flac






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 13 at 9:41







      Hand of C'thuhlu

















      asked Jan 13 at 8:25









      Hand of C'thuhluHand of C'thuhlu

      5681415




      5681415






















          1 Answer
          1






          active

          oldest

          votes


















          3














          This is because of how MP3 encoding (or actually, both encoding and decoding) works. See the technical FAQ:




          Why is a decoded MP3 longer than the original .wav file?



          Because LAME (and all other MDCT based encoders) add padding to the
          beginning and end of each song. LAME embeds the amount of padding in the ancillary data of the first frame of the MP3 file. (LAME INFO tag).




          Continuing:




          All decoders I have tested introduce a delay of 528 samples. That
          is, after decoding an mp3 file, the output will have 528 samples of
          0's appended to the front. This is because the standard
          MDCT/filterbank routines used by the ISO have a 528 sample delay. It
          would be possible to write a MDCT/filterbank routine with a 0 sample
          delay (see description of Takehiro's MDCT/filterbank routine used in
          LAME encoding below) but I dont know that anyone has done this.
          Furthermore, because of the overlapped nature of MDCT frames, the
          first half of the first granule (1 granule=576 samples) doesn't have a
          previous frame to overlap with, resulting in attenuation of the first
          N samples.




          It gets more technical if you read on, but this should summarize the issue.






          share|improve this answer
























          • Is there a way to cut out the 528 sample delay directly through ffmpeg?

            – Hand of C'thuhlu
            Jan 14 at 1:28











          • Ok, it seems like ffmpeg -ss 0.0528 -i fileA.flac fileB.mp3 seem to do the trick, though I don't understand why, since the file uses a sample rate of 44100Hz, shouldn't 528 samples take 0.0119 seconds?

            – Hand of C'thuhlu
            Jan 14 at 1:42













          • -ss 0.0528 means there's an offset of 0.0528 seconds, not samples. But you can trim samples like so: stackoverflow.com/a/39809030/435093

            – slhck
            Jan 14 at 13:49











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "3"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1393704%2fflac-to-mp3-conversion-offsets-sound-by-a-few-ms%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          This is because of how MP3 encoding (or actually, both encoding and decoding) works. See the technical FAQ:




          Why is a decoded MP3 longer than the original .wav file?



          Because LAME (and all other MDCT based encoders) add padding to the
          beginning and end of each song. LAME embeds the amount of padding in the ancillary data of the first frame of the MP3 file. (LAME INFO tag).




          Continuing:




          All decoders I have tested introduce a delay of 528 samples. That
          is, after decoding an mp3 file, the output will have 528 samples of
          0's appended to the front. This is because the standard
          MDCT/filterbank routines used by the ISO have a 528 sample delay. It
          would be possible to write a MDCT/filterbank routine with a 0 sample
          delay (see description of Takehiro's MDCT/filterbank routine used in
          LAME encoding below) but I dont know that anyone has done this.
          Furthermore, because of the overlapped nature of MDCT frames, the
          first half of the first granule (1 granule=576 samples) doesn't have a
          previous frame to overlap with, resulting in attenuation of the first
          N samples.




          It gets more technical if you read on, but this should summarize the issue.






          share|improve this answer
























          • Is there a way to cut out the 528 sample delay directly through ffmpeg?

            – Hand of C'thuhlu
            Jan 14 at 1:28











          • Ok, it seems like ffmpeg -ss 0.0528 -i fileA.flac fileB.mp3 seem to do the trick, though I don't understand why, since the file uses a sample rate of 44100Hz, shouldn't 528 samples take 0.0119 seconds?

            – Hand of C'thuhlu
            Jan 14 at 1:42













          • -ss 0.0528 means there's an offset of 0.0528 seconds, not samples. But you can trim samples like so: stackoverflow.com/a/39809030/435093

            – slhck
            Jan 14 at 13:49
















          3














          This is because of how MP3 encoding (or actually, both encoding and decoding) works. See the technical FAQ:




          Why is a decoded MP3 longer than the original .wav file?



          Because LAME (and all other MDCT based encoders) add padding to the
          beginning and end of each song. LAME embeds the amount of padding in the ancillary data of the first frame of the MP3 file. (LAME INFO tag).




          Continuing:




          All decoders I have tested introduce a delay of 528 samples. That
          is, after decoding an mp3 file, the output will have 528 samples of
          0's appended to the front. This is because the standard
          MDCT/filterbank routines used by the ISO have a 528 sample delay. It
          would be possible to write a MDCT/filterbank routine with a 0 sample
          delay (see description of Takehiro's MDCT/filterbank routine used in
          LAME encoding below) but I dont know that anyone has done this.
          Furthermore, because of the overlapped nature of MDCT frames, the
          first half of the first granule (1 granule=576 samples) doesn't have a
          previous frame to overlap with, resulting in attenuation of the first
          N samples.




          It gets more technical if you read on, but this should summarize the issue.






          share|improve this answer
























          • Is there a way to cut out the 528 sample delay directly through ffmpeg?

            – Hand of C'thuhlu
            Jan 14 at 1:28











          • Ok, it seems like ffmpeg -ss 0.0528 -i fileA.flac fileB.mp3 seem to do the trick, though I don't understand why, since the file uses a sample rate of 44100Hz, shouldn't 528 samples take 0.0119 seconds?

            – Hand of C'thuhlu
            Jan 14 at 1:42













          • -ss 0.0528 means there's an offset of 0.0528 seconds, not samples. But you can trim samples like so: stackoverflow.com/a/39809030/435093

            – slhck
            Jan 14 at 13:49














          3












          3








          3







          This is because of how MP3 encoding (or actually, both encoding and decoding) works. See the technical FAQ:




          Why is a decoded MP3 longer than the original .wav file?



          Because LAME (and all other MDCT based encoders) add padding to the
          beginning and end of each song. LAME embeds the amount of padding in the ancillary data of the first frame of the MP3 file. (LAME INFO tag).




          Continuing:




          All decoders I have tested introduce a delay of 528 samples. That
          is, after decoding an mp3 file, the output will have 528 samples of
          0's appended to the front. This is because the standard
          MDCT/filterbank routines used by the ISO have a 528 sample delay. It
          would be possible to write a MDCT/filterbank routine with a 0 sample
          delay (see description of Takehiro's MDCT/filterbank routine used in
          LAME encoding below) but I dont know that anyone has done this.
          Furthermore, because of the overlapped nature of MDCT frames, the
          first half of the first granule (1 granule=576 samples) doesn't have a
          previous frame to overlap with, resulting in attenuation of the first
          N samples.




          It gets more technical if you read on, but this should summarize the issue.






          share|improve this answer













          This is because of how MP3 encoding (or actually, both encoding and decoding) works. See the technical FAQ:




          Why is a decoded MP3 longer than the original .wav file?



          Because LAME (and all other MDCT based encoders) add padding to the
          beginning and end of each song. LAME embeds the amount of padding in the ancillary data of the first frame of the MP3 file. (LAME INFO tag).




          Continuing:




          All decoders I have tested introduce a delay of 528 samples. That
          is, after decoding an mp3 file, the output will have 528 samples of
          0's appended to the front. This is because the standard
          MDCT/filterbank routines used by the ISO have a 528 sample delay. It
          would be possible to write a MDCT/filterbank routine with a 0 sample
          delay (see description of Takehiro's MDCT/filterbank routine used in
          LAME encoding below) but I dont know that anyone has done this.
          Furthermore, because of the overlapped nature of MDCT frames, the
          first half of the first granule (1 granule=576 samples) doesn't have a
          previous frame to overlap with, resulting in attenuation of the first
          N samples.




          It gets more technical if you read on, but this should summarize the issue.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 13 at 13:48









          slhckslhck

          161k47447470




          161k47447470













          • Is there a way to cut out the 528 sample delay directly through ffmpeg?

            – Hand of C'thuhlu
            Jan 14 at 1:28











          • Ok, it seems like ffmpeg -ss 0.0528 -i fileA.flac fileB.mp3 seem to do the trick, though I don't understand why, since the file uses a sample rate of 44100Hz, shouldn't 528 samples take 0.0119 seconds?

            – Hand of C'thuhlu
            Jan 14 at 1:42













          • -ss 0.0528 means there's an offset of 0.0528 seconds, not samples. But you can trim samples like so: stackoverflow.com/a/39809030/435093

            – slhck
            Jan 14 at 13:49



















          • Is there a way to cut out the 528 sample delay directly through ffmpeg?

            – Hand of C'thuhlu
            Jan 14 at 1:28











          • Ok, it seems like ffmpeg -ss 0.0528 -i fileA.flac fileB.mp3 seem to do the trick, though I don't understand why, since the file uses a sample rate of 44100Hz, shouldn't 528 samples take 0.0119 seconds?

            – Hand of C'thuhlu
            Jan 14 at 1:42













          • -ss 0.0528 means there's an offset of 0.0528 seconds, not samples. But you can trim samples like so: stackoverflow.com/a/39809030/435093

            – slhck
            Jan 14 at 13:49

















          Is there a way to cut out the 528 sample delay directly through ffmpeg?

          – Hand of C'thuhlu
          Jan 14 at 1:28





          Is there a way to cut out the 528 sample delay directly through ffmpeg?

          – Hand of C'thuhlu
          Jan 14 at 1:28













          Ok, it seems like ffmpeg -ss 0.0528 -i fileA.flac fileB.mp3 seem to do the trick, though I don't understand why, since the file uses a sample rate of 44100Hz, shouldn't 528 samples take 0.0119 seconds?

          – Hand of C'thuhlu
          Jan 14 at 1:42







          Ok, it seems like ffmpeg -ss 0.0528 -i fileA.flac fileB.mp3 seem to do the trick, though I don't understand why, since the file uses a sample rate of 44100Hz, shouldn't 528 samples take 0.0119 seconds?

          – Hand of C'thuhlu
          Jan 14 at 1:42















          -ss 0.0528 means there's an offset of 0.0528 seconds, not samples. But you can trim samples like so: stackoverflow.com/a/39809030/435093

          – slhck
          Jan 14 at 13:49





          -ss 0.0528 means there's an offset of 0.0528 seconds, not samples. But you can trim samples like so: stackoverflow.com/a/39809030/435093

          – slhck
          Jan 14 at 13:49


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Super User!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1393704%2fflac-to-mp3-conversion-offsets-sound-by-a-few-ms%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Plaza Victoria

          Puebla de Zaragoza

          Musa