a patch to split up dab.c

[GoogleCodeExporter]

Please find attached a patch that will hopefully make the workings of dab.c
a little clearer.

Original issue reported on code.google.com by mansourm...@gmail.com on 30 May 2010 at 6:30

Attachments:

• libmsr-dab-split.patch

[GoogleCodeExporter]

That's an interesting patch. Peter has been working on refactoring the dab and 
other 
code into three major parts: integration of dab functions into libmsr proper, 
dab as a 
standalone program in utils/, and finally integrating all of this together with 
autoconf.

Is that something you'd like to work into a patch with Peter?

Original comment by ioer...@gmail.com on 31 May 2010 at 6:41

[GoogleCodeExporter]

Original comment by ioer...@gmail.com on 31 May 2010 at 6:41

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

What follows are a few comments and ideas regarding the direction of dab in 
libmsr that I hoped to share.

1. dab should be split up into several tools:
   The first being one or more of some sort of ``getaudio'' tool that will obtain audio from *somewhere* -- whether that is from a file using libsndfile, or from a Linux kernel using OSS/ALSA, or an iPhone's mic, etc. -- and print textual representation of that data to the standard output file (e.g. one line per sample, one column per channel).
   The second should be dab proper. dab should accept PCM data in textual format from the standard input file, decode any Biphase mark code it sees, and print binary to the standard output file.
   That is, imagine:
     $ getaudio --file FILE | ab --decode -
     $ getaudio --alsa | ab --decode -
     $ getaudio --android > FILE && ab --decode FILE
   etc.

2. Both dab and dmsb should be separated into library and tool components (e.g. 
libab and libmsb) and expanded to be capable of not only decoding but encoding 
as well.
   For example, imagine:
     $ echo ';12345?' | \
     > msb --encode - | ab --encode - | \
     > ab --decode - | msb --decode -
     ;12345?
   etc.

If the above sounds good, I'd like to go ahead and attempt a patch to implement 
this. Anyway, these are ideas for the long term. In the meantime, I will 
attempt a nicer patch than the one above very soon.

Original comment by mansourm...@gmail.com on 4 Jul 2010 at 4:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I forgot one thing. To get an idea of what I mean by textual sound data, please 
refer to the sox documentation[1]:

``.dat
    Text Data files. These files contain a textual representation of the sample data. There is one line at the beginning that contains the sample rate. Subsequent lines contain two numeric data items: the time since the beginning of the first sample and the sample value. Values are normalized so that the maximum and minimum are 1 and -1. This file format can be used to create data files for external programs such as FFT analysers or graph routines. SoX can also convert a file in this format back into one of the other file formats.''

Thus, with Linux, one could also imagine something along the lines of:
  $ sox -t alsa default -t dat - | ab --decode - | msb --decode -

: )

[1] http://sox.sourceforge.net/soxformat.html

Original comment by mansourm...@gmail.com on 4 Jul 2010 at 4:11