Unwanted silence added after exporting in Mp3

[Blast]

Hello.

First, I'm frech so don't blame me if I make a lot of mistakes please. I'm curently using Windows 8 with Audacity 2.0.2.
I have the hobby of making vidéo games and I take care of everthing including the music.
You maybe now that most of video games musics makes a loop without any interruption. Mine at least are supposed to work this way.
After composing them with a MIDI editor, I make some adjustment including the staring and ending cup of the music before exporting in Mp3. It's just that even when I cut to the edge of the blue wave (don't know the name, sorry), Audacity always add that silence after exporting and that silence is audible when playing with the loop. And I can see it when openning my music again with Audacity.

Anyone got an idea for this problem ?

[steve]

I have replied to your post here: http://forum.audacityteam.org/viewtopic ... 58#p213658

[Robert J. H.]

lame has a delay of 576 samples (half of the mp3 Frame size).
Additionally, there can be Zeros added to the end of the track.
Lame stores this values in order to provide gapless playback, but the Player/Decoder must Support this Option.
Listen to the comparison between WMP and foobar2000 to see this Option in Action.
Besides, when you reopen the mp3 in Audacity, the delay will be doubled due to the Decoding.
That's an issue that should be recognized automatically - don't know why this isn't the case in Audacity.

[DVDdoug]

That's an issue that should be recognized automatically - don't know why this isn't the case in Audacity.

Audacity is an audio editor, not an audio player. IMO, an audio editor shouldn't mess with the data that comes out of the MP3 decoder. It might be even more confusing if Audacity was hiding the silence/gap.

[Robert J. H.]

That's an issue that should be recognized automatically - don't know why this isn't the case in Audacity.

Audacity is an audio editor, not an audio player. IMO, an audio editor shouldn't mess with the data that comes out of the MP3 decoder. It might be even more confusing if Audacity was hiding the silence/gap.

I don't think so.
Audacity Transfers any imported Format into its own. In this respect, it is only interested in the raw data - as it was inherent in the original.
Delay and Zero padding do not Content any useful Information.
Furthermore, the original Duration is artificially expanded with each Encoding/decoding.
The data can't be transferred back into the original mp3 stream, if this were possible, the integrity of the Frames should be insured.
Audacity could at least move the Audio to the left - just as it does with the latency correction.

[steve]

lame has a delay of 576 samples (half of the mp3 Frame size).

Is that correct? I thought that the overall encoder/decoder delay was undefined, hence the addition of metada by some encoders to enable gapless playback to be faked (a feature supported by Lame).
576 samples is the size of one "granule", and the first half of the first granule does not have a previous frame to overlap with it, causing an attenuation of the first few samples (the number of which depends on the window type).

In short, Lame (and all other MP3 encoders) add padding to the start of the file.

Some technical information from Lame (http://lame.sourceforge.net/tech-FAQ.txt)

4. Why cant MP3 files be seamlessly spliced together?

There are several reasons this is *very* difficult (but not impossible):

The MP3 data for frame N is not stored in frame N, but can be spread
over several frames. In a typical case, the data for frame N will
have 20% of it stored in frame N-1 and 80% stored in frame N.
If the encoder builds up a large bit reservoir,
the data for frame N can actually be stored 4088 bits back in
the bitstream. Then if a very hard-to-encode passage comes up,
then the encoder is free to use the normal bits for this frame
plus up to 4088 more. The resulting data will then take up
several frames. The starting negative offset
in the bitstream for the data associated with a given frame in bytes is
given by main_data_begin.

Thus chopping a mp3 file on a frame boundary will almost always result
in the corruption of the data in that frame. mpg123 will report
such errors as "cant seek past beginning of file" or something
like that.

A proper cut-and-past job could be done, but it would have to
separate all the data from the frame headers, and then
replace the frame headers in the correct location in the new
stream. One problem: this may generate data for frame N that
is stored too far back, say 4100 bits back. In that case, the
main_data_begin field will be incorrect since it can be at most 4088.

The article goes on to say that MP3s can be concatenated seamlessly, but it required splicing the frames from the end of one stream with the frames at the start of the next, which is not something that Audacity (or any other editor) could do for making an audio clip that can be looped seamlessly - it would need to be done on playback.

[Robert J. H.]

lame has a delay of 576 samples (half of the mp3 Frame size).

Is that correct? I thought that the overall encoder/decoder delay was undefined, hence the addition of metada by some encoders to enable gapless playback to be faked (a feature supported by Lame).

576 samples should be correct for Lame (Encoding mode). It is the value that is listed on:
http://wiki.hydrogenaudio.org/index.php ... lay_values
(Take also a look at the older Version values, some interesting explanations there).
Foobar2000 lists this value too on the property tab of a file that I've exported.
The length of the file was 1153 samples i.e. a Frame + 1sample to force an additional frame.
The decoded file had in Audacity a length of 3456 samples (3 Frames)

Code: Select all

General
Duration 0:00.026 (1 153 samples)
Sample rate 44100 Hz
Channels 1
Bitrate 69 kbps
Codec MP3
Codec profile MP3 VBR V4
Encoding lossy
Tool LAME3.99r
Other
<ENC_DELAY> 576
<ENC_PADDING> 1727
<MP3_ACCURAT... yes
<MP3_STEREO_... mo o
<MP3_STEREO_... mono

The Initial delays differ only from Encoder to Encoder (as can be seen in the table on the Website above).
The Zero padding causes additional delay apart from the constant one.
Audacity could easily remove this silent parts from the decoded mp3 when
- the Encoder was Lame
- the info tag is available
- similar with other Encoders.

But that doesn't help blast for his game playback Problem.
The great question is how the mp3s are decoded within the game - which engine/library is used and if it can read the Lame info-tag.
The command line of Lame has two Switches that could provide gapless playback, e.g.
--nogap <file 1> ... <file n> makes the files playable one after the other.
I assume that this is made possible by combining the Frames of the two streams (as described in Steve's reply). An actual Looping is harder to achieve, I guess (although it works fine with Foobar2000). Even if no suitable playback device is available, The mp3s can be cut such that the streams seem seamless (what a horrible language ), at least if your Music has any pause in it where you can split and remove the 1152 samples or whatever Foobar2000 and similar Software tells you.
If you want to look at the different Switches of Lame:
Open the Export menu, enter any file Name (not important), choosse external program and press Options.
Enter

Code: Select all

lame --longhelp - -

enable the Output Option and press OK.
Now press Save. The command Output window will Show all available Options for the installed Lame Version without exporting any file.

[steve]

But that doesn't help blast for his game playback Problem.
The great question is how the mp3s are decoded within the game

I prefer the question "why use MP3"?
If space allows, WAV ( or headerless PCM) could provide high quality sound, more efficient decoding and gapless looping. If space dictates a compressed format, then OGG could provide high quality sound, good compression ratio and gapless looping.

[Robert J. H.]

Good point.
Furthermore, if I programmed games, I would use a Format that is quite rarely used and with a structure or Bit rate that is not readily recognized by a commonplace Player.
Just an additional copy protection in a way.