Create sample size limit

FMOD Engine
1

Hello,

I think I’ve hit up against a sample length limit of CreateSample…

Somewhere between 20,274,048 samples and 21,170,304 samples, absolute positioning seems to go out: the start of the track seems to get truncated (2 channels, standard amazon mp3s).

For this particular task I do need the whole track in memory, I use a stream on other occasions.

Wondering if I’m missing an option to increase this? Is this intentional? I can manually populate an array for the time being, was curious about any limit.

Many thanks in advance

2

do you have an example file that you’re talking about? 20 million samples is only like 7 minutes or something. I don’t know what you mean by the ‘absolute position seems to go out’. Are you talking about an issue with setPosition, or you’re just losing the start of large mp3s?

3

Hi Brett, many thanks.

Track is: Control (feat. Joe Le Groove), Defected In the House Ibiza 2016.

Given:

result = system->createSound(pPath, FMOD_DEFAULT | FMOD_CREATESAMPLE, nullptr, &sound);

unsigned int uBytePosition = 0;
unsigned int uByteCount = 1024 * 2 * 2;

result = sound->lock(uBytePosition, uByteCount, reinterpret_cast<void**>(&pByteData), nullptr, &read, nullptr);

With tracks larger than a certain size the data returned for uBytePosition -> uBytePosition + uByteCount is not accurate. Seems the start is truncated, not the end, so the data returned is ‘further along’ than it should be.

Is that useful?

FTR, I’ve switched in a manually populated byte array (using a stream) and the data is correct. (It does take considerably longer though!)

Let me know is you need any more info.

Thanks again,

4

Hi Brett,

Done some more testing. Seems I need the AccurateTime flag on CreateSample. It only seems necessary on the larger files as this hasn’t come up before? Mayby I just got lucky…

With that flag all seems ok. Many thanks.

5

FMOD_ACCURATETIME is used with VBR sounds. As it doesn’t know the length in PCM at the start, if you load it as a sample (and not a stream), it is going to only allocate memory for what it assumes is the size (based on the first few frames) and more likely would cut the end of the sound off.
Also seeking would not be accurate if it was a stream, so FMOD_ACCURATETIME scans the file and makes a seek table for accurate seek positioning with a VBR file.
If it is decompressed into memory then seeking is just like seeking in PCM, and is not affected.