Not seeing the right Bit Rate for FLAC files

[Jerry]

In either the tooltip or custom Bit Rate column for FLAC files, I'm always seeing a much larger, fixed rate than I expect and different from what I see in other programs (like Foobar2000 or MediaInfo), or even from what is shown in XYplorer's Metadata window for these files. For example, I have a regular 16bit 44khz stereo FLAC that has a specific bit rate of 911 kbps, as shown in those other places, but in the tooltip or Bit Rate column appears as 1411 kBit/sec, which is what appears for all 16bit 44khz FLAC files. I'm only interested in the 911 kbps number. Why doesn't XYplorer show this file-specific number everywhere for the Bit Rate?

[admin]

The Bit Rate is calculated the usual way AFAIK: bit_rate = ((sample_rate / 1000) * bits_per_sample * channels)

Those values are directly read from the file bytes by XY. Don't know what I could improve here.

[Jerry]

The Bit Rate is calculated the usual way AFAIK: bit_rate = ((sample_rate / 1000) * bits_per_sample * channels)
Those values are directly read from the file bytes by XY. Don't know what I could improve here.

Why can't you instead just show here and everywhere else the Bit rate that you show in the Metadata window?

[admin]

In the Metadata window I just report what the shell reports. This depends on the installed codecs (On my system it reports nothing for FLAC.)

In the list and tooltips I calculate the BitRate natively, no codecs involved.

But maybe I do it totally wrong. I just re-researched this and found a totally different BitRate formula, hmmm:

Code: Select all

BitRate = (FileSizeInBytes * 8) / TimeInSeconds

Would that formula give you the expected results?

[Jerry]

I just re-researched this and found a totally different BitRate formula, hmmm:

Code: Select all

BitRate = (FileSizeInBytes * 8) / TimeInSeconds

Would that formula give you the expected results?

Yes, it most certainly does, if you use the actual file size on disk. And it works for multi-channel files, WAV and presumably any other format as well.

[admin]

OK, got it.

My old formula is okay for uncompressed formats.
The other formula is okay for compressed formats (like FLAC, lossless but compressed).

So the fix is on the way. Thanks!

[Jerry]

Wonderful! And I would also add that it works fine for files that have had their gain increased internally, which results in a larger size and bit rate.

[TheQwerty]

In the Metadata window I just report what the shell reports. This depends on the installed codecs (On my system it reports nothing for FLAC.)

In the list and tooltips I calculate the BitRate natively, no codecs involved.

But maybe I do it totally wrong. I just re-researched this and found a totally different BitRate formula, hmmm:

Code: Select all

BitRate = (FileSizeInBytes * 8) / TimeInSeconds

Would that formula give you the expected results?

Surely this should be stream size not file size, right?
Otherwise the file's metadata is going to have an impact on its bitrate which is not correct.

EDIT: Looks like Xiph does indeed calculate it using file size:

Code: Select all

8.0 * (float)(_stat.st_size) / (1000.0 * (float)streaminfo.data.stream_info.total_samples / (float)streaminfo.data.stream_info.sample_rate),

[Jerry]

Surely this should be stream size not file size, right? Otherwise the file's metadata is going to have an impact on its bitrate which is not correct.

True, and I guess a problem if one pastes entire opera librettos or large cover art into the metadata. But I would think the relative magnitude would be somewhat limited most of the time. I did the calculation a number of times on various files, all containing basic metadata, and the numbers matched what I see elsewhere, at least to enough significant digits. Don could maybe keep the old calculation for mp3's which are smaller. Not sure if he always has access to the internal stream size, and across all the various audio formats. My lossless FLAC files vary from 10MB to as much as 5.2GB (for single multi-track 8-channel image files). Even at the low end, 10,000 characters of meta data would just skew the result by 0.1%. Certainly tolerable, for me, at least.