I have implemented a custom codec for aac files. It’s using the codec fileread and fileseek methods to read data and seek data (thus not directly accessing file).
Previous version of fmod worked great. With latest version 1.03.03 the codec completely fails to decode stream.
Apparently the data returned by fileread is not what is inside the file. It also seems to incorrectly start with "M4A ".
Furthermore depending of the use of CREATESTREAM or CREATECOMPRESSEDSAMPLE in createSound the data returned by fileread is completely different when it should not be.
Why would a codec not expect the file handle provided to it to be rewinded by default to the beginning of the file?
It’s as simple as fmod rewinding and calling seek(handle, 0) before calling open on the codec. I don’t understand why fmod would leave the file handle at a random location?
I think it worked in earlier version of fmod for me because I was registering my codec with priority 0 and it was the first one invoked. Now that I use 1000, other codecs or parsers may be invoked prior to opening my codec.
If the codec sample was showing a seek(0) was required in the rawopen, or the documentation explained it, this would be better.
There may have been a legacy reason for this, or even a performance reason, as some codecs don’t always seek to the start, so seeking to 0 would be redundant, but looking at it now maybe its because all our internal codecs do their own seek, or not many other people writing their own codecs have this issue, because in 10 years i cant remember anyone mentioning it.
I’ve added a seek before the open callback now though as I think it would make sense, and i’ll put this in for 1.03.04 release.
regards,
Brett
It’s not accurate to say that it hasn’t been required in older versions. the codec has never ‘auto seeked’ to 0 for you, even in FMOD Ex, i’ve just checked the FMOD Ex code to confirm this, where it originated from.
Even if you are reading from memory, that should obviously be irrelevant to the codec - it still has to use the read and seek callbacks even if it comes from file or memory.
Hi,
You should always seek your file data to 0 first, because other codecs will be reading the file , this is probably your issue with m4a being read.
On .m4a files I can see that 'M4A " starts at 8 bytes in, so its not unusual that a RIFF reader for example may have consumed 2 dwords (ID/length) just before reading with this codec.
CREATESTREAM and CREATECOMPRESSEDSAMPLE also has no affect on your data, but only certain codecs are able to support FMOD_CREATECOMPRESSEDSAMPLE so codecs before yours were probably rejected before even reading any data. Only built in MP2/MP3/ADPCM/VORBIS/XMA and AT9 is going to allow FMOD_CREATECOMPRESSEDSAMPLE support. Your codec will not support it, and will instead just decompress it as if it was FMOD_CREATESAMPLE.
I am really not understanding what you are saying. The previous version of fmod worked fine and the new one does not.
Again I am not accessing the file directly, I use the API fmod gives me via the codec to read and seek.
I am expecting that fmod would do the right thing and seek for me to the beginning of the file prior to calling open on my codec.
What else am I to do, call codec->seek myself to 0 prior to doing anything? The behavior changed obviously.
Also there’s no example of a custom codec that shows how to implement it. It took me hours experimenting and fishing for information online from very old versions.
For example, there’s no explanation that your’re supposed to return ERR_FORMAT if your codec does not suport the format so fmod continues looking for another one.