Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Decoding VU meter ".bin" files (Read 1071 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Decoding VU meter ".bin" files

I've been working on decoding the abandoned foo_vis_vumeter.dll's ".bin" file format. I have figured out almost all of it, but asking for help for the final component. If anyone is interested in collaborating or already knows the answers please chime in.

Here is what I know (when looking at the ".bin" file after decompression):
  • The header is 8 bytes and contains the WORDs that describe the width of the background bitmap, the height of the background bitmap, the frame count, and some yet unknown value (maybe has to do with LED).
  • After the header, there is an array of address offsets for each frame. Note that some addresses might be repeated due to the "knots" curve.
  • After the address array there is a bitmap array for the background image. Format is B8G8R8A8 UNORM but the alpha (being mostly all zeroes) should be ignored.

Here is what I'm missing:
  • Lastly, there are listings for each frame at the offsets described by the array mentioned previously. I assume they describe the needle position (and/or LED state). In what format, I'm not sure. They all start with the 0xfff7 pattern repeated several times (possibly for alignment) and end in 0x80. Given that there are not as many bytes as the background image:
    • I assume it must be a delta (possibly describing what pixel/color component to overwrite/operate on).
    • It might also be further compressed. But I can't find an obvious signature.
    • Unsure if or how the unknown header might figure into all of this.
    • I think I found the DLL's and editor routine that does this decoding/drawing in Ghidra but I don't recognize the functionality. Maybe someone more familiar with common algorithms can tell if it's some standardized function.

Re: Decoding VU meter ".bin" files

Reply #1 –
Nevermind.

Re: Decoding VU meter ".bin" files

Reply #2 –
Quote from: oops on
Nevermind.
BTW, would an x64 remake of VU meter component have a feature to use more "accurate" ballistics (to match with the behavior of analog VU meter hardware) instead of simple RMS averaging? And how about VU meter skins for AIMP?

Re: Decoding VU meter ".bin" files

Reply #3 –
Short answer, YES!
Been using Foobar2000 since 2013, works perfect for me

Re: Decoding VU meter ".bin" files

Reply #4 –
I’m sorry, but I just wanted to say a huge THANK YOU for looking into this, as the VU Meters are the most thing I’ve been wanting to get converted to 64bit! I eagerly await your progress, god speed.
 

Re: Decoding VU meter ".bin" files

Reply #5 –
Quote from: TF3RDL on
BTW, would an x64 remake of VU meter component have a feature to use more "accurate" ballistics (to match with the behavior of analog VU meter hardware) instead of simple RMS averaging? And how about VU meter skins for AIMP?
The quality of any visualization will be limited to the care whoever designed the panel put into the response curve ("knots" in VUEditor).

But it is not a physics simulation nor is it intended to be. While I did my best to replicate the transfer function of the circuit from my real VU meter (traced with great pains by hand from the board into SPICE and simulated) there are lots of artistic liberties taken in the translation to DirectX/Win32 bitmaps. As an extra, I have implemented ITU-R BS.1770-5 as an option if you prefer that over simple peak detection or RMS. And there are knobs to tweak the sensitivity and the decay/rise factors for the different panels.

I reiterate my previous comment from another thread about these being toys. If you are looking for an accurate instrument, this will be nowhere near that.

Cool sim by the way, I threw in my test tones and it outputs as expected. And on the last question, I don't have any personal interest in implementing the AIMP method.