fix(audio): strict base64 body input decoding

[oOraph]

context:

javascripts libs tend to send as base64 what is not base64: it's <rfc-2397-prefix>,<base64-payload>

https://stackoverflow.com/questions/20517429/parse-base64-string-coming-fron-javascript-front-end-data-uri-rfc2397

data:audio/mpeg;base64,ENCODEDDATA

-> this is not valid base64 and we should just raise a bad request to that

what happened so far is that the python ends up sending the whole data into
https://docs.python.org/3/library/binascii.html#binascii.a2b_base64

and somehow manages to "decode" even non valid b64 string (how ? discarding non valid chars ? or just by taking the data byte by byte and stripping the 4 upper bits that should be null - but are not necessarily for non valid b64 chars - in every byte and concatenating the kept bits altogether to get the decoded data ? I don't know -> would need to reverse the hexdump)

so we ended up injecting decoded tainted data (garbage header + audio data) into the transformers lib

and somehow the python lib used by this one to parse audio data sometimes managed to recognize the data as proper audio (eg discard the garbage). For example it worked for mp3 but not flac data (don't know the mp3 struct but there must be some header that the lib expected, discarding all padding/garbage before)

in short the data injected into inference was not the same as the data originally sent by the user and we were lucky it answered sth (and even more it answered something relevant to what had been requested)

An (imo bad) alternative to this fix could be to be more flexible and parse rfc 2397 properly when found but there is no reason to call b64 what is not

[ErikKaum]

good find, thank you 👍