48 bit long


#1

I am playing round with a new file format and needed precision to the nearest nano second so opted for Int64 over 32 (as this would only give me a couple of seconds as signed int ). But as Int64 there’s lots of wasted zeros bloat in file.

I have working 6 byte 48bit being shifted and cast. But I can hear Jules saying don’t do it. I remember a couple of years back seeing something in documentation about a truncated long (or I could be thinking of something else entirely) that would do the same operation but probably better… Is there anything like that ?


#2

It depends just how much space the file is wasting!

If these are huge files and 25% of them is a lot of space then yes, it’s probably worth packing the numbers better. But if these are timestamps then you could probably do even better with something like a variable-length integer format, as you’re unlikely to need all 48 bits, so could save even more space.


#3

So yes I am trying to cut down on space as I representing audio as sums of it’s sinusoids which lends itself to different types of signal processing with the added bonus of no phase issues. Basing part of it on the way MP3 works by filtering into very discrete bands I can predict where a sinusoid will cross in the nano seconds realm.

The data is basically saved in frames then channels then domains and takes the form of Position (long) , Amplitude (float) pos, amp, pos, amp, pos
So by truncating to 48 bit I would be reducing a recursive 12 bytes down to 10 bytes so worthwhile I think. and 48 bits would give me nano seconds upto 78 hours which way over the intended use. Shrinking 6 bytes down to 5 bytes would only leave just over 3 mins though and use cases are easily going to exceed that so 6 byte / 48bit long seems a good trade off.

Whats the best way of writing this in an output file stream.


#4

I get what your saying about the variable length int which I could express as an Int32 offset from the frames boundaries but It was a little nightmare getting the indexing working efficiently on playback (variable number of sinusoids per second) and the only constant bounds are the frames. Think I’ll keep my sanity for a little while longer before tackling that level of optimisation,