# Custom codec open callback

**URL:** <https://qa.fmod.com/t/custom-codec-open-callback/11361>\
**Category:** FMOD Studio\
**Created:** [March 28, 2014, 9:47pm UTC](https://qa.fmod.com/t/custom-codec-open-callback/11361 "2014-03-28T21:47:31Z")\
**Posts on this page:** 5\
**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:47pm UTC](https://qa.fmod.com/t/custom-codec-open-callback/11361/1 "2014-03-28T21:47:31Z")

</div>

When returning FMOD\_ERR\_FORMAT from a custom codec open callback to let FMOD know a codec is not capable of opening the file format specified, FMOD used to try other codecs before failing completely. It now fails right away no matter what priority is passed to registerCodec.

---

<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 30, 2014, 11:51am UTC](https://qa.fmod.com/t/custom-codec-open-callback/11361/2 "2014-03-30T11:51:24Z")

</div>

Hm I just added a custom raw codec and returned FMOD\_ERR\_FORMAT in the open callback, it was an mp3 and the mp3 then succeeded to open.

Did you happen to accidentally use FMOD\_CREATESOUNDEXINFO::suggestedsoundtype at the same time?

---

<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, 3:57pm UTC](https://qa.fmod.com/t/custom-codec-open-callback/11361/3 "2014-03-31T15:57:40Z")

</div>

Are you registering the codec with priority 0 or higher? It behaves as I describe when I use 0.  
I do not set the suggested type.

---

<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, 7:24pm UTC](https://qa.fmod.com/t/custom-codec-open-callback/11361/4 "2014-03-31T19:24:45Z")

</div>

The problem is not with the priority but rather that the data returned by codec-\>fileread is not correct and thus the codec crashes.  
Try opening an mp3 or m4a file with a codec registered with priority 0. It crashes nicely.  
Opening ogg file seems to bypass any custom codec even when registered with a priority 0.

---

<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:07am UTC](https://qa.fmod.com/t/custom-codec-open-callback/11361/5 "2014-04-01T03:07:13Z")

</div>

You’re right, priority is irrelevant.  
My test simply opens an mp3, returns FMOD\_ERR\_FORMAT from the open callback, then it continues to successfully open as an mp3 using the built in mp3 codec.  
I’m not sure what ogg or mp3 really have to do with the behaviour, it makes no difference to the system. I changed it to ogg and the file opens as ogg correctly.

It sounds to me like you’re not returning FMOD\_ERR\_FORMAT in the right place. You’re doing it in the open callback and not the read callback right? You shouldnt be getting any read callbacks if you failed the codec open on the open call.