Flac to mp3 conversion offsets sound by a few ms
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:
Any idea why this happens and how I can fix it?
ffmpeg conversion mp3 flac
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
add a comment |
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:
Any idea why this happens and how I can fix it?
ffmpeg conversion mp3 flac
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
add a comment |
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:
Any idea why this happens and how I can fix it?
ffmpeg conversion mp3 flac
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
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:
Any idea why this happens and how I can fix it?
ffmpeg conversion mp3 flac
ffmpeg conversion mp3 flac
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
edited Jan 13 at 9:41
Prime_Aqasix
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
asked Jan 13 at 8:25
Prime_AqasixPrime_Aqasix
5711415
5711415
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Jan 13 at 13:48
slhckslhck
161k47447470
Is there a way to cut out the 528 sample delay directly through ffmpeg?
– Prime_Aqasix
Jan 14 at 1:28
Ok, it seems likeffmpeg -ss 0.0528 -i fileA.flac fileB.mp3seem 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?
– Prime_Aqasix
Jan 14 at 1:42
-ss 0.0528means 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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
answered Jan 13 at 13:48
slhckslhck
161k47447470
Is there a way to cut out the 528 sample delay directly through ffmpeg?
– Prime_Aqasix
Jan 14 at 1:28
Ok, it seems likeffmpeg -ss 0.0528 -i fileA.flac fileB.mp3seem 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?
– Prime_Aqasix
Jan 14 at 1:42
-ss 0.0528means 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
add a comment |
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.
answered Jan 13 at 13:48
slhckslhck
161k47447470
Is there a way to cut out the 528 sample delay directly through ffmpeg?
– Prime_Aqasix
Jan 14 at 1:28
Ok, it seems likeffmpeg -ss 0.0528 -i fileA.flac fileB.mp3seem 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?
– Prime_Aqasix
Jan 14 at 1:42
-ss 0.0528means 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
add a comment |
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.
answered Jan 13 at 13:48
slhckslhck
161k47447470
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.
answered Jan 13 at 13:48
slhckslhck
161k47447470
answered Jan 13 at 13:48
slhckslhck
161k47447470
answered Jan 13 at 13:48
slhckslhck
161k47447470
answered Jan 13 at 13:48
slhckslhck
161k47447470
161k47447470
Is there a way to cut out the 528 sample delay directly through ffmpeg?
– Prime_Aqasix
Jan 14 at 1:28
Ok, it seems likeffmpeg -ss 0.0528 -i fileA.flac fileB.mp3seem 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?
– Prime_Aqasix
Jan 14 at 1:42
-ss 0.0528means 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
add a comment |
Is there a way to cut out the 528 sample delay directly through ffmpeg?
– Prime_Aqasix
Jan 14 at 1:28
Ok, it seems likeffmpeg -ss 0.0528 -i fileA.flac fileB.mp3seem 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?
– Prime_Aqasix
Jan 14 at 1:42
-ss 0.0528means 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?
– Prime_Aqasix
Jan 14 at 1:28
Is there a way to cut out the 528 sample delay directly through ffmpeg?
– Prime_Aqasix
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?– Prime_Aqasix
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?– Prime_Aqasix
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
