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: Optimal size for a looping audio file (Read 1521 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Optimal size for a looping audio file

Is it possible to squeeze a long sequence of repetitive (looping) identical parts so that the critical part will be encoded only once and then referenced?

Suppose you have a 5-minute long mp3 file consisting of a the following part:

A

and suppose you have a 30-minute long mp3 file consisting of the following parts:

A A A A A A

which means the content of the first file is repeated 6 times.

I would expect a smart encoder to produce a second file with a size comparable with the first. In practice, however, I noticed the second file tends to be 6 times bigger.

Basically, my question is in the vein of this one:

https://www.reddit.com/r/howto/comments/69kh39/how_do_i_recompress_a_very_very_long_repetitive/

Of course, I know that I can put the first file on repeat, but I'm asking if I can achieve this at the encoder level, not at the user level.

Re: Optimal size for a looping audio file

Reply #1
MP3 can't do that.

There are some audio formats for video games that might be able to do it, but as far as I know it's not automatic (you have to manually set repeat points) and it's difficult to actually play those formats outside of the games that used them.

Re: Optimal size for a looping audio file

Reply #2
CRI's ADX has built-in support for looping, but you have to craft the input file carefully and set the loop positions manually in order to get seamless looping. In general, music does not contain identical samples that repeat; a song may have a chorus that is repeated several times, but since each repetition is a separate performance of the same words, an encoder can't compress the chorus once and then reference that single instance multiple times, since each chorus repetition is not identical. The words are the same, but the samples that the encoder compresses are not.

Re: Optimal size for a looping audio file

Reply #3
You might have more luck with WAV compressed by large dictionary archiver like RAR, 7z...

Re: Optimal size for a looping audio file

Reply #4
Not really what you are looking for but it looks funny...  :D

Code: [Select]
FILE "LOOP.MP3" MP3
TRACK 01 AUDIO
INDEX 01 00:00:00
TRACK 02 AUDIO
INDEX 01 00:00:00

I also heard about ordered chapters in MKV but I have zero experience with them.
gold plated toslink fan

Re: Optimal size for a looping audio file

Reply #5
Applications like Garage Band use loops in AIFF files - although I don't know what players support it.
A few of them here: http://www.macloops.com . Some for free; so you can check the player application in question.

Re: Optimal size for a looping audio file

Reply #6
.wav, including the lossy ones like ADPCM, can contain marker (one position) and region (from position A to B). Different software can determine how to make use of these data. For example, I inserted a marker and a region in Audition and they can be read by Reaper and other programs like Sound Forge, Vienna SoundFont Studio and so on.
X

As mentioned, these things are never automatic, so not what the OP wants to have. Also, similar topics have been shown up several times.
https://hydrogenaud.io/index.php/topic,121739.0.html
https://hydrogenaud.io/index.php/topic,123560.0.html

Re: Optimal size for a looping audio file

Reply #7
Thank you all for your answers.

I'm thinking about something like rutra80 said:

You might have more luck with WAV compressed by large dictionary archiver like RAR, 7z...

but I'm wondering whether this would work with an mp3 file (instead of wav). I know it's compressed, but I would expect those loops will compress to similar or identical mp3 frames - am I wrong? If it works, the only thing that remains is to find a player that can play the mp3 from inside a rar/7z archive.

Worth to try, I guess.

Also, this is my first post here (and I am a noob regarding to audio) and I'm quite impressed by the nice atmosphere and the quick, helpful and divers replies. Nice forum for sure.

Re: Optimal size for a looping audio file

Reply #8
but I'm wondering whether this would work with an mp3 file (instead of wav). I know it's compressed, but I would expect those loops will compress to similar or identical mp3 frames - am I wrong?

MP3 works in blocks of 1152 samples, so then your loop segment should be an integer multiple of 1152 for that to hold ... I think?
How are other lossless codecs doing?

Re: Optimal size for a looping audio file

Reply #9
It won't work with MP3 or similar codecs as at the last stage they already do huffman coding which nullifies redundancy. You must keep it in redundant form for archiver to find it.


Re: Optimal size for a looping audio file

Reply #11
I also heard about ordered chapters in MKV but I have zero experience with them.
Ordered chapters are used to link across files. The most common use case is when dealing with a TV show, the opening and ending sequence for anime is usually the same for every episode, so you can encode the OP and ED one time each, and then have each episode file link to the external OP and ED files to avoid encoding the same material a dozen times.

 

Re: Optimal size for a looping audio file

Reply #12
It won't work with MP3 or similar codecs as at the last stage they already do huffman coding which nullifies redundancy.

Here you got a loop. Notice the size.
Yes huffman coding is on frame level so if you align loop to frames (or even do more or less brutal joining of streams) then archiver will do its job. But it's an artificially crafted mp3 and I was replying to topic starter, should have quoted him. In real world chances that a loop will be aligned with frames is unrealistic (loops being bit identical is already a special situation).
There were floating around joke zips - several hundred bytes large that decompressed to gigabytes, or that decompressed to themselves etc. But these are just laboratory experiments. Although it might be possible to craft a tool that in some special cases would more or less achieve what topic starter wants.