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?
Track is: Control (feat. Joe Le Groove), Defected In the House Ibiza 2016.
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!)
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.