Error using StringIO in audio transcription

[leejarvis]

Hello,

According to the documentation for OpenAI::Resources::Audio::Transcriptions#create, the file parameter accepts StringIO. However, I'm unable to get this to work (similarly, it says it also accepts a String, but I can't get that to work either).

Here's an example:

require "openai"

file = File.open(ARGV[0])
stringio = StringIO.new(File.binread(ARGV[0]), "rb")

client = OpenAI::Client.new
transcription = client.audio.transcriptions.create(model: "gpt-4o-transcribe", file: stringio)

puts transcription.text

It works OK for the file object, but not the stringio object, which raises the following error:

{:url=>"https://api.openai.com/v1/audio/transcriptions", :status=>400, :body=>{:error=>{:message=>"Unsupported file format", :type=>"invalid_request_error", :param=>"file", :code=>"unsupported_value"}}} (OpenAI::Errors::BadRequestError)

Am I missing something or should this work?

The file I'm using is the wav sample here: https://www.kaggle.com/datasets/pavanelisetty/sample-audio-files-for-speech-recognition

Thank you

[leejarvis]

I got this to work by building an OpenAI::FilePart instance:

stringio = StringIO.new(File.binread(ARGV[0]), "rb")
file_part = OpenAI::FilePart.new(stringio, filename: "audio.wav", content_type: "audio/wav")
transcription = client.audio.transcriptions.create(model: "gpt-4o-transcribe", file_part: file_part)

Which is fine, but highlighting that this doesn't work like the documentation suggests it should. Looks like perhaps the filename and content type are explicitly required if there's no file object?

[ms-jpq]

Humm, I think we should adjust the documentation 👍.

Will close this when a PR is out 🔜

[jbeckwith-oai]

Confirmed the current behavior on main (8be999ac). A raw StringIO is emitted with filename upload and content type application/octet-stream, so the request does not preserve enough format metadata for the API to recognize the audio. Wrapping it in OpenAI::FilePart with an extension-bearing filename and content type is the correct workaround; the generated documentation should make that requirement clear.