Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Another approach for sound loops in MP3 (Read 4887 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Another approach for sound loops in MP3

Hello everyone,

I have a hardware MP3 player (using the STA013 chip) and a customer wants a sound to be looped (gapless) in this device. Solutions that I have read so far suggest that the MP3 player/decoder should handle it (using the LAME tag), but that is no option for me, because the device uses a hardware decoder.

I need a solution in the MP3 file itself. While this is impossible in the general sense (because the properties of the MP3 file format), perhaps there is a way out in a specific situation. The criterions are that you must be able to produce your own sound clips, or at least that you can modify them to meet specific requirements.

Here is my suggestion:

1. You must prefix the audio file with a fixed number of "silent" samples. The number of samples must be equal to the 1152 minus the encoder delay (576 samples in LAME). I am assuming MPEG1 Layer 3 audio, hence 1152 samples per frame.

2. The total number of samples must be a multiple of 1152 minus the encoder delay. So a clip could be 44352 samples (39 frames - 576 for the LAME encoder delay) .

3. If this clip is encoded, the first true sample will fall at a frame boundary and the last sample will fall on a frame boundary too. Actually, one would expect the last frame of the MP3 file to be completely full, but I have noticed that LAME adds a full frame of silence if the calculation drops out thus.

4. Encode with the bit reservoir disabled. Frames should not depend on predecessors now. With LAME, the option is --nores. For the sake of quality, it is best to encode in VBR.

5. LAME will write a XING/LAME tag (a full frame of silence as far as a hardware MP3 decoder is concerned) and a frame with an encoder delay plus the (1152 - 576) samples of silence from our source WAV file. At the end, there is another full frame of silence. These three frames can be simply cut off.

Now I am asking for comments. As none of the above was particularly hard to come by, I am probably not the first to have thought about it. Yet, I cannot find references and I do not see a flaw in the reasoning. Am I forgetting something?
(Okay, I am forgetting the decoder delay. But I figure that it is only relevant in the very first iteration --and I do not mind incurring a delay start-up.)

Any critisism? If so, thanks in advance.
(Sure, I should simply try it myself. Right now, I do not have a hardware player under my hands anymore; they have all been sold. Early September I will be able to test this approach. In the mean time, I'll try to write some software to support the operations mentioned above. But I have have blundered in the reasoning, it is not worth the effort... Hence my question here.)

Thiadmer

 

Another approach for sound loops in MP3

Reply #1
If it is going to loop completely, then disabling the reservoir is pointless, as the first frame depends on nothing.

Gapless decoding, on the other hand, is kind of impossible if your decoder can't skip samples. It will need to chop off the specified encoder delay, and compensate for its own delay, and then truncate the file to account for the remainder of the padding. If it cannot do this, then it will at least be able to start the stream over, but it won't be gapless.

Even if you somehow prevent the encoder from padding the clip, the ends won't be the same, and the difference may result in audible popping on every repeat.

Another approach for sound loops in MP3

Reply #2
MDCT is an overlapping transform.

Another approach for sound loops in MP3

Reply #3
Quote
MDCT is an overlapping transform.


Quite right. I had not considered this. That is a set-back.

Thanks,
Thiadmer

Another approach for sound loops in MP3

Reply #4
With a slightly more complex procedure (than the one that started this thread), I have come up with an MP3 file that contains a 1 second beep (a sine wave of approx. 1 kHz). When concatenating another copy of this file at its end, I get a 2 second beep. Add one more, and it gives a 3 second beep.

Gapless, clickless.

I concatenated the files with the DOS copy command; specifically:
Code: [Select]
copy /b f1225.mp3 + /b f1225.mp3 longbeep.mp3

When playing the resulting file in WinAmp, I heard no click, plop or gap. WinAmp cannot possibly have used a "sample skipping" trick, because it does not expect a LAME tag halfway the file. In any case, I know that the f1225.mp3 file has no LAME tag (I stripped it off after encoding). When opening the file in a home-made wave editor that uses the Windows ACM to read MP3 data, I saw no glitch at the junction point.

In conclusion, I am convinced that the file f1225.mp3 is loopable. I am not sure whether this trick works in general, or whether it just works with sine waves.

Side note 1: It is not very well known, but the copy command can concatenate files with the "+" operator between source files. The "/b" sets binary mode for each source file (this is required; otherwise "copy" assumes text files and inserts a carriage-return/line-feed sequence in the middle of the output file).

Side note 2: the original file must not have a glitch/plop when played in a loop, for obvious reasons. This is why I chose a frequency of 1125 Hz: it fell out just right for a 1 second beep.

Another approach for sound loops in MP3

Reply #5
Quote
With a slightly more complex procedure (than the one that started this thread), [...]

This "slightly more complex procedure" takes the overlapping nature of MDCT into account, by the way. My original procedure did not work well, as Gabriel predicted.

Quote
Gapless decoding, on the other hand, is kind of impossible if your decoder can't skip samples. It will need to chop off the specified encoder delay, and compensate for its own delay, and then truncate the file to account for the remainder of the padding. If it cannot do this, then it will at least be able to start the stream over, but it won't be gapless.

I had initially not responded to this, because I did not understand what it meant. Now I think that kode54 is referring to a repeat cycle that:
a) starts up the decoder
b) pushes all frames for an MP3 sound clip into the decoder
c) shuts down the decoder
d) repeat: go back to step a)

This may be typical for a file based player, and indeed if you do that, you will incur a decoding delay at each iteration. However, the STA013 MP3 decoder chip gets its data over a serial link and it does not know a thing about files. My repeat loop looks more like:
a) push all frames for the MP3 clip into the decoder, which must already have been initialized
b) repeat step a)

And this explains too why I have been appending binary MP3 files to each other with a binary copy, and verifying the output (see my previous post). That actually comes close to the above loop procedure.

So I do not have a decoder delay (except, perhaps, on the very first iteration). Instead of having my decoder chop off the encoder delay and the remainder of the last frame, I suggest to do that in a pre-processing step.

Another approach for sound loops in MP3

Reply #6
Hello everyone,

I have (finally) described my approach to looping MP3 tracks in detail on my company's web site, at http://www.compuphase.com/mp3/mp3loops.htm. There is also some software that automates the procedure, plus example clips.

* I have tested the result both on a PC (using the "copy concatenate" command as described in the article mentioned above) and on a hardware MP3 player.
* I have tested with music clips (carefully selected to be seamlessly looping) and with pure tones.
* For the pure tones, I also inspected the result visually in a sound editor (after having glued several tones together). No anomally at the junction points was seen.

In short: I think it works.

Incidentally, I originally tested with pure tones only. The idea was that any kind of glitch would be more easy to notice if it occurred during a pure tone. I started using music clips after reading the "Gapless - Hydrogenaudio Knowledgebase" article (section "Testing for gapless"). However, reason #1 (that the page gives) does not make much sense: if the source clip isn't gapless, indeed you cannot expect the result to be gapless. Reason #2 does not apply to my method of testing where I concatenate two copies of an MP3 file; the decoder then sees a single file, with the junction point of the original files in the middle. I am in favour of testing with pure tones. My colleague suggested a "sweep tone", which may be a good option as well.

Kind regards,
Thiadmer