Allow sample rate to be read in from filename

[samyk]

Suggestion: It would be nice if the sample rate could be stored/read in from a filename. I often store it in the filename anyway, and it would be an easy way to transfer it around. Eg, pulling out /-(\d+)([mkbg]?)sps/i and calculating it from there.

[miek]

This already happens for the default filenames coming from osmocom_fft, see #80

[samyk]

Ah, nice, but that only seems to work for .cfile's. It would be nice for other formats to support this as well. Additionally, a tooltip when rolling over 'Sample rate' stating how to use it would be useful to explain it.

[schneider42]

Yes, it only works for files which end in .cfile. I think we can drop that limitation.

[battlesnake]

Audacity attempts to guess input format and 90% of the time gets it wrong, in addition to having an annoying limit on sample rate, which is how I came across Inspectrum.

I'm also supportive of reading some info (e.g. sample rate, sample format) from the filename, and ideally allowing the user to provide a list of multiple regexes for parsing filenames, rather than attempting to guess like Audacity or to use a hardcoded format.

I may be able to work on this two weeks from now if nobody has a problem with it.

[dkozel]

SigMF is trying to make an open source standard for signal file metadata.
https://github.com/gnuradio/SigMF/blob/master/sigmf-spec.md

[garverp]

GNURadio also has a metadata format [1] with sample rate, center frequency, data type, timestamps, etc. On file load could look for an associated GR header, read sample rate, center frequency, and data type. Then plot timestamps...

PWG

[1] http://gnuradio.org/doc/doxygen/page_metadata.html

[battlesnake]

I think these are two separate approaches, which probably deserve separate issues:

1. Reading metadata from a separate side-car file.

2. Reading metadata from the raw data file's filename.

[sm0yyq]

Cant say i don't get any sample rate from my complex32s files, but maybe i shoulden't either?