specrec --type not propagating to header file?

[perks]

So actually wondering, does specrec support saving files as fc32? Ran into this error when trying to load a saved .dat and .dat.hdr file with GNURadio's File Meta Source

Executing: /usr/bin/python2 -u /home/chris/tools/top_block.py

Traceback (most recent call last):
  File "/home/chris/tools/top_block.py", line 147, in <module>
    main()
  File "/home/chris/rbs-lads/tools/top_block.py", line 135, in main
    tb = top_block_cls()
  File "/home/chris/tools/top_block.py", line 112, in __init__
    self.connect((self.blocks_file_meta_source_0, 0), (self.qtgui_freq_sink_x_0, 0))    
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 47, in wrapped
    func(self, src, src_port, dst, dst_port)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 110, in connect
    self.primitive_connect(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 5331, in primitive_connect
    return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError: itemsize mismatch: file_meta_source0:0 using 4, freq_sink_c0:0 using 8

Also did notice that despite specifying the --type field, the header information still reports it as being short, 4 byte:

HEADER 0
Version Number: 0
Sample Rate: 195.312kSPS
Timestamp (Unix Epoch): 12/31/1969 19:00:00
Integer Seconds: 0.0
Fractional Seconds: 0.0
Item Size: 4 Bytes
Data Type: short (1)
Complex? True
Header Length: 193 bytes
Extra Length:  44
Extra Header?  True
Segment Size (bytes): 3.90656M
Segment Size (items): 976.64k
Chunk Time: 5.0004S
Total Time elapsed: 5.0004S

Extra Header:
item_num: 0
rx_freq: 4.5e+08

Is this intended behaviour or am I doing something wrong?

[garverp]

Yea, looks like the metadata is hardcoded for .sc16. The data should actually be .fc32, however. Action item is to propagate --type CL arg to metadata function correctly. We primarily use sample rates which are on the border of what our systems can handle so we always use .sc16 and convert with gr_fileman because it requires 1/2 the write speed so you get more MSPS through. Thanks for the feedback.

[perks]

Got it! I don't think I having any pressing need for fc32 at the moment, but Ill look into tooling gr_fileman for conversion. Also maybe a bit off topic but do you any best practices from fully converting say a sc16 file completely to a fc32 file, without doing the multiplication between time * samples to make sure you don't lose anything? Currently some of my scripts are doing that, but maybe there was an obvious idiomatic way that I was missing.

Thanks!

[garverp]

What do you mean by "losing anything"? Do you mean lose precision on the timestamps? gr_fileman will convert .sc16 to .fc32, including headers. It just passes the headers through unless you ask for a subset of the file, in which case it finds the closest timestamp and interpolates. In terms of selecting subsets of the file, you can do it based on sample index OR time. Time uses the metadata and is very useful for cutting out time-aligned sections from multiple synchronous records.