I didn’t notice until today that my app always reports “1411 kbps” for MP3 content. I’ve been using my old 3.74 formula:
[code:1i3p18rv]m_kbps = m_lenBytes / m_lenMsec * 8[/code:1i3p18rv]
…because FMOD 3.74 reports raw sound bytes.
In FMOD-EX, m_lenBytes is a decoded length:
[code:1i3p18rv]Result = FMOD_Sound_GetLength(fmod_Sound, m_lenPcm, m_lenMsec, m_lenBytes)[/code:1i3p18rv]
Do we still have access to raw length? If not, how about the first byte position?
- stdev asked 13 years ago
I personally don’t see much use in the number of raw bytes, so I agree that a function to get the bitrate would probably be more logical.
Besides, wouldn’t just getting the filesize to the same thing for most cases? It could be off a few bytes due to tags, but usually it will be prety close to what you want I would think.
- Adion answered 13 years ago
[quote:6dkzdqeg]Besides, wouldn’t just getting the filesize to the same thing for most cases? It could be off a few bytes due to tags…[/quote:6dkzdqeg]
Well, I would not recommend that FMOD scrap the sound-byte length just so authors can use a method that will be be innaccurate to varying degrees 99% of the time. That’s not good programming.
I would like to have accurate bitrate descriptions every time an audio file is opened–rather than close approximations most of the time. 😉
I intentionally used the term “sound byte” when I started this thread because I trust that every supported language has some means to determine file size. I do not use FMOD to determine file size; Visual Basic has its own function.
FMOD 3.74 returns the number of sound bytes for the types of media my application opens. By “sound bytes” I am referring to the number of bytes that encode sound information, or–if you prefer–file size less any header(s) and other bytes that do not decode into sound.
Should FMOD-EX do the same? Probably.
That byte length is “undefined” or awkward with some formats is incidental. Let me make a suggestion:
Keep the TIMEUNIT_RAWBYTES thing and just return ZERO (and perhaps a useful error message) in situations where FMOD cannot determine the number of sound bytes.
Authors can use the byte length to derive bitrates; and it may prove useful in ways we can’t think of now.
My two cents,
The only reason I need the byte total is to derive the media’s (average) bitrate; so an explicit bitrate just makes my job easier.
I’m not saying that this is the way to go, because other authors might have different reasons for wanting to know the number of sound bytes in compressed media. If so, perhaps they can add comment to guide your decision.
Please login first to submit.