# Looping mp3 broken in 1.03.03

**URL:** <https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360>\
**Category:** FMOD Studio\
**Created:** [March 28, 2014, 9:43pm UTC](https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360 "2014-03-28T21:43:11Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![c0diq](https://avatars.discourse-cdn.com/v4/letter/c/278dde/32.png) [@c0diq](https://qa.fmod.com/u/c0diq)\
**Post date:** [March 28, 2014, 9:43pm UTC](https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360/1 "2014-03-28T21:43:11Z")

</div>

When I try to create a sound using mp3 and FMOD\_CREATECOMPRESSEDSAMPLE on OSX, the sound does not loop.  
Using FMOD\_CREATESAMPLE or FMOD\_CREATESTREAM works.  
The previous FMOD version used to work fine.

```
result = system->createSound(Common_MediaPath("wave.mp3"), FMOD_LOOP_NORMAL | FMOD_2D | FMOD_CREATECOMPRESSEDSAMPLE, 0, &sound);
```

---

<div class="post-metadata">

**Author:** ![c0diq](https://avatars.discourse-cdn.com/v4/letter/c/278dde/32.png) [@c0diq](https://qa.fmod.com/u/c0diq)\
**Post date:** [April 1, 2014, 5:16am UTC](https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360/2 "2014-04-01T05:16:31Z")

</div>

CBR = constant bit rate  
VBR = variable bit rate

Additional metadata don’t have an influence on the fact the codec is constant vs variable.  
Per your explanation, that would mean that any mp3 with ID3 tag would be considered VBR which is not correct.  
Also the fact that having an ID3 tag would break looping in fmod is worry some.

---

<div class="post-metadata">

**Author:** ![brett](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/brett/32/261_2.png) [@brett](https://qa.fmod.com/u/brett)\
**Post date:** [April 1, 2014, 5:26am UTC](https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360/3 "2014-04-01T05:26:32Z")

</div>

i did not say ‘tags’, i said ‘non standard tags’ or i should have just said ‘non standard data’ which happens all the time with mp3 files.  
If you want consistent, predictable data, use FSB format which can use mp3 encoding.

Of course fmod supports tags, but unless you want fmod to scan the whole file byte by byte (which btw is what FMOD\_ACCURATETIME does) how do you expect FMOD to instantly calculate the accurate length of the file? mp3 does not have a ‘format’, it is a raw bitstream.

---

<div class="post-metadata">

**Author:** ![brett](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/brett/32/261_2.png) [@brett](https://qa.fmod.com/u/brett)\
**Post date:** [March 31, 2014, 5:24am UTC](https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360/4 "2014-03-31T05:24:25Z")

</div>

Hi C0diq,  
Thanks for writing. You are right about that. It is a combination of a few different things that lead to this, and a refactoring of our resampler recently which introduced a bug.  
The 3 factors that cause this are

1. need to use FMOD\_CREATECOMPRESSEDSAMPLE
2. need to use a non FSB based file
3. file needs to be VBR and have the length incorrectly calculated for it.

To eliminate point 3, you can work around this issue by adding FMOD\_ACCURATETIME to your createSound call (so that the length is correctly calculated for it). This should fix the issue in the meantime while the new patch release comes out with the resampler fix in it.

---

<div class="post-metadata">

**Author:** ![c0diq](https://avatars.discourse-cdn.com/v4/letter/c/278dde/32.png) [@c0diq](https://qa.fmod.com/u/c0diq)\
**Post date:** [March 31, 2014, 6:40pm UTC](https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360/5 "2014-03-31T18:40:53Z")

</div>

The use of FMOD\_ACCURATETIME in createSound fixes the problem however the issue is not happening just for mp3 VBR.

---

<div class="post-metadata">

**Author:** ![brett](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/brett/32/261_2.png) [@brett](https://qa.fmod.com/u/brett)\
**Post date:** [April 1, 2014, 3:49am UTC](https://qa.fmod.com/t/looping-mp3-broken-in-1-03-03/11360/6 "2014-04-01T03:49:35Z")

</div>

if you mean non VBR mp3, then the file is probably including data like non standard tags that are making the length value incorrect, as a CBR calculation is usually a raw size value divided by a fixed framesize (calculated by reading the first few frames) to work out how many frames are in the mp3, then multiplying that by 1152 pcm samples to get total pcm length.
