<div dir="ltr"><div>The design of such a format would depend on the end goal. You mentioned that you wanted to save space on your server. A streaming compression of the current textual format should work quite well, and even better if we do a sort of a preprocessing of it to "delta encode" the date: i.e, if a series if, say: [ 241, 234, 221, 201, 100, 43, 0, -10...], convert it to [ 241, -7, -13, -20, -101, -57, -43, -10...]. <br></div><div><br></div><div>If the use only involves streaming access to data (i.e, process each entry and move on), the compression works really well, and most compression formats allow both, streaming while writing, and streaming while reading (meaning one won't need to fully decompress a file on the filesystem before using it); look at tools like zcat, zstdcat, etc. <br></div><div><br></div><div>In practice you will find that [text format+ compression] will be fairly close to [binary format + compression] in final size. <br></div><div>Compression obviously will reduce random access to data, so if your intended use involves seeking randomly around in the data, things get tricky. <br></div><div><br></div><div>If the format is intended to be shared with other people, and/or manage large collections of such data, either use hdf5[1] or look into it for inspiration. <br></div><div>If that sounds too complicated, then protobufs[2] might be another option. Both hdf5 and protobufs benefit from having readily available code for access to the data for later analysis, and from having hundreds of man-years of bugfixes and portability fixes behind them. <br></div><div><br></div><div>Again, depending on the use case, another option might be to store the data in a sqlite[3] database file, its an underrated option for large amounts of data: here the binary conversion to and fro can be handled by the sqlite tools themselves, and you have access to the data in a fully random-access fashion. There are ways for sqlite to do online compression of data as well[4], incase you find the standard size reduction from going to binary isn't enough. <br></div><div><br></div><div>Having dealt with custom binary formats for large amounts of data quite a bit, I tend to recommend against doing that if standard options can instead be used: there are a large number of pitfalls in going binary, both when writing the data, as well as when reading it back; Greg brought up endianness, then theres framing(indicating the start if each "row" of data, in case a few bytes got corrupted on disk, thus allowing the rest to still be recovered), versioning (if you change the data format, how do you have the reading code still remain able to read the older format), debugging (its very hard to be 100% sure that a binary data you intended to write, typically there will be no error messages from the code and no crashes - just wrong and misleading results due to miswritten/misread data), etc.</div><div><br></div><div>Just my 0.02USD.<br></div><div><br></div><div>-Abhishek</div><div><br></div><div>[1]: <a href="https://www.neonscience.org/about-hdf5">https://www.neonscience.org/about-hdf5</a></div><div>[2]: <a href="https://github.com/protocolbuffers/protobuf">https://github.com/protocolbuffers/protobuf</a></div><div>[3]: <a href="https://www.sqlite.org/about.html">https://www.sqlite.org/about.html</a> ("Think of SQLite not as a replacement for 
Oracle but
as a replacement for fopen()")</div><div>[4]: <a href="https://sqlite.org/zipvfs/doc/trunk/www/readme.wiki">https://sqlite.org/zipvfs/doc/trunk/www/readme.wiki</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 27, 2019 at 1:46 AM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bill Gaylord <<a href="mailto:chibill110@gmail.com" target="_blank">chibill110@gmail.com</a>> writes:<br>
<br>
> Hello,<br>
><br>
>     I am working on making a binary format for rtl_power to save space on<br>
> my server for observing the spectrum. I am wondering if anyone else would<br>
> be interested in this idea.<br>
> I am hoping keep the same format in terms of how the data is organized in<br>
> the file but instead of using text use some form of binary format. For<br>
> example for the date and time I think using a unix epoch timestamp would<br>
> work.<br>
><br>
> I am hoping to receive any comments or criticism.<br>
<br>
My suggestions are:<br>
<br>
  Think about whether you want the binary format to be portable.  This<br>
  means being more careful about types and also endianness.<br>
<br>
  Post a draft file format for comments.<br>
<br>
  With a binary format for an existing text format, it would be nice to<br>
  have programs (pipes ideally) that convert text->binary and<br>
  binary->text.<br>
<br>
<br>
For portability, I think the obvious answer is that the file format<br>
should be independent of CPU type, compiler, and specifically<br>
endiannesss.   Thus you are writing a  format that could be used over<br>
the network (even if it's only intended to be stored).   This means you<br>
have to choose fixed-width types, and you have to store in a particular<br>
endianness.  I am 99% sure that the network protocol standard is big<br>
endian, and I think you should follow that.  I think there is precedent<br>
in things like sqlite.  For pgsql I think so, but there is a culture of<br>
having to use pg_dump to change versions (and as a result pg_dump is<br>
100% satisfactory; see my comment above about converters).  I don't know<br>
about mysql.<br>
</blockquote></div>