Chris,
Excellent, then I will start benchmarking tomorrow :)
Thanks!
On Sat, Jul 16, 2016 at 9:35 PM, Chris Kuethe <chris.kue...@gmail.com>
wrote:
> Flac doesn't really need to know what the actual sample rate is; you
> could tell it 500e3 and you should get the same data out after
> compressing and decompressing it.
>
> On Sat, Jul 16, 2016 at 11:20 AM, Dave NotTelling <dmp250...@gmail.com>
> wrote:
> > Marcus & Dan,
> >
> > Thank you very, very much for the detailed information!
> >
> > Dan: That's exactly what I thought when going into this at first. But, I
> > decided to give gzip a shot just to see how well it did. Turns out that
> (at
> > least for bursty environments) it almost halves the size of the original
> > file. It should be noted that the file was in fc32 format so there were
> > likely a lot of unused bits there (or so I guess).
> >
> > Marcus: I have been giving thought to truncating some of the bits.
> Going as
> > far as thinking about dropping from sc16 to sc8. I have worked with 8
> bit
> > sample files before and had plenty of success demodulating, so I'm
> thinking
> > that it might be an okay path to go down. Dynamic range goes to hell,
> but
> > it it's worked in the past... I think that re-packing as 12 bit would
> give
> > considerable space savings without a lot of CPU overhead. I'll have to
> give
> > that one a go :) I really like your idea of using FLAC. Just a quick
> > Google search netted
> http://www.rtl-sdr.com/compressing-filtering-iq-data/.
> > What concerns me is that when I tried to use the command line flac in
> Ubuntu
> > it said that the sample rate must be between 1 and 655349 Hz. I'll have
> to
> > poke around at it to see what happens when I set an incorrect bit rate
> > (maybe a multiple of will be fine?).
> >
> > Thank you both!
> >
> > -Dave
> >
> > On Sat, Jul 16, 2016 at 5:14 AM, Marcus Müller <marcus.muel...@ettus.com
> >
> > wrote:
> >>
> >> Ah!
> >>
> >> On 16.07.2016 11:04, Marcus Müller wrote:
> >> > and maybe, but this is really speculation, you can just modify the
> >> > error calculation to just ignore the 4 lower bits of the actual sample
> >> > data, and safe another few percents of data volume.
> >> Yeah, there's a FLAC__stream_encoder_set_bits_per_sample[0] function--
> >> guess that you don't need to modify anything. Also, there's a whole
> >> listing of things .._set_compression_level[1] sets internally. This
> >> approach (using FLAC as lossless waveform encoder) might be really
> >> interesting.
> >>
> >>
> >>
> >> [0]
> >>
> >>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#gabfa3c989377785cda7c496b69dcb98cb
> >> [1]
> >>
> >>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#ga07fc8c7806381a055a1eef26387e509f
> >>
> >> _______________________________________________
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
