Quick Intro/Loop tutorial

[CE]

Here's a quick "How To" on using kbandressen's new Intro/loop feature:

music data/path/file.bor {offset}

Offset is a position in bytes that the music will return to when it loops; for example if you had a 128000 byte bor file, setting offset to 64000 would put it almost exactly halfway through the song (there is a 160 byte header in the bor file).



[The formula is:]

(File Size in bytes - 160) * (Time to loop back to / Total song length)

So if your intro is 10.21 seconds long, the song is 1:41.32, and the file size is 2354543 bytes:

(2354543 - 160) * (10.21/101.32) = 237250

To apply this to one of my tracks, I opened my WAV file in my audio editor. I am currently using Soundforge. A great alternative would be Audacity which is free software, released under the GNU General Public License, and available for Windows, GNU/Linux, BSD and Mac: http://audacity.sourceforge.net/

I cut my file down so the main part loops like it should and checked where the intro ends. In my file that's exactly after 4.019 seconds. The entire file is 76.419 seconds long (1m and 16,419s).


Position of where the intro ends / Total song length:
4.019 / 76.419 = 0,052591632970858032688205812690561


I saved the WAV without header, or loop marks, etc. Then I converted it to .bor using convert.exe (or wav2bor.exe). The resulting file is 1.685.220 bytes big.


File Size in bytes - .bor file header (160 bytes):
1685220 - 160 = 1685060


Final calculation of the offset:
1685060 *  0,052591632970858032688205812690561 = 88620,057053874036561588086732357


Important is the number before the comma (88620). I copied it from calc.exe into memory with CRTL+C, and pasted it in 'mylevel.txt':


#music    data/path/file.bor {offset}
music      data/music/bar.bor 88620


...and the loop starts exactly at 4:019 seconds 

[kbandressen]

Also note that you don't need the decimal point.  The engine will just round it off if you specify it.

[Bloodbane]

 Thanks for the tutorial CE! 

Also note that you don't need the decimal point.  The engine will just round it off if you specify it.

 Ah, I've thought so.

[CE]

Also note that you don't need the decimal point.  The engine will just round it off if you specify it.

 Ah, I've thought so.

Fixed. - I wasn't 100% sure if it would have made a difference, as in my test I tried to be as accurate as possible to see if I could get it to do what I wanted and was pleasantly surprised that it looped as perfectly as it did, so I didn't do any further tests.

[Edgeworth]

a small refininement of the above method:

1. in your audio editor, switch the timescale view to Samples.
2. load wav, find loop points. make sure all audio is trimmed after the loop-end.
3. look at the loop-start value. voil?, your offset.
 
*click for pic*

e.g.,

Sample rate (Hz): 44100
Channels: 2

F = BOR file size (bytes): 4290950
h = BOR header size (bytes): 160
Ns = Loop start (samples): 668709
Nt = Total length (samples): 4290790

offset = (F - h) * (Ns / Nt)
= (4290950 - 160) * (668709 / 4290790)
= 668709
= Ns = Loop start (samples)

so if Total length = file size - header, it's fair to deduce that (for stereo) BOR ADPCM encoding allocates 1 byte per sample, which simplifies things greatly.

[Plombo]

a small refininement of the above method:

1. in your audio editor, switch the timescale view to Samples.
2. load wav, find loop points. make sure all audio is trimmed after the loop-end.
3. look at the loop-start value. voil?, your offset.
 
*click for pic*

e.g.,

Sample rate (Hz): 44100
Channels: 2

F = BOR file size (bytes): 4290950
h = BOR header size (bytes): 160
Ns = Loop start (samples): 668709
Nt = Total length (samples): 4290790

offset = (F - h) * (Ns / Nt)
= (4290950 - 160) * (668709 / 4290790)
= 668709
= Ns = Loop start (samples)

so if Total length = file size - header, it's fair to deduce that (for stereo) BOR ADPCM encoding allocates 1 byte per sample, which simplifies things greatly.

Not quite.  That number has to be divided by two because BOR ADPCM allocates 1 byte per 2 samples for mono (1-channel) sound.  So the loop offset in the above example would be 334353 if the song is mono, 668709 if it is stereo.

[Edgeworth]

a small refininement of the above method:

1. in your audio editor, switch the timescale view to Samples.
2. load wav, find loop points. make sure all audio is trimmed after the loop-end.
3. look at the loop-start value. voil?, your offset.
 
*click for pic*

e.g.,

Sample rate (Hz): 44100
Channels: 2

F = BOR file size (bytes): 4290950
h = BOR header size (bytes): 160
Ns = Loop start (samples): 668709
Nt = Total length (samples): 4290790

offset = (F - h) * (Ns / Nt)
= (4290950 - 160) * (668709 / 4290790)
= 668709
= Ns = Loop start (samples)

so if Total length = file size - header, it's fair to deduce that (for stereo) BOR ADPCM encoding allocates 1 byte per sample, which simplifies things greatly.

Not quite.  That number has to be divided by two because BOR ADPCM allocates 1 byte per 2 samples.  So the loop offset in the above example would be 334353, not 668709.

Thanks for the correction. The example should have read that loop point = offset if the sample rate is 22050Hz, not 44100Hz.

[Plombo]

Actually...the sample rate (the number of samples played every second) doesn't affect how samples are stored.  It only affects how fast they are played back.

[Bloodbane]

 Have you guys tried it? I have problem with setting this and even posted it in bugs section. Now after I think it over, maybe I didn't set it right.

[Edgeworth]

Actually...the sample rate (the number of samples played every second) doesn't affect how samples are stored.  It only affects how fast they are played back.

Well yes, but a .wav with a sample rate of 22050Hz would have half the number of samples of a .wav of same length and bit-depth with a sample rate of 44100Hz. The former would be played back at half the rate of the latter.

What I should have said was that regardless of the actual source .wav's sample rate, the offset appears to be relative to 22050Hz. Basically:

Offset = Loop start * (22050 / Sample rate)

Since you've implemented ogg vorbis support (very useful, thanks ) we can now assume a sample rate of 44100Hz. Simplified:

Offset = Loop start / 2

which corresponds to your observation.

Bloodbane, I have tested for 11025, 22050 and 44100Hz, and can supply the test files if you need them. I couldn't figure out why only 22050Hz looped properly until now.