search

EliasOenal / multimon-ng

GNU General Public License v2.0
925 stars 206 forks source link

Randomly misses EAS headers #99

Open abirger opened 6 years ago

abirger commented 6 years ago

I've noticed that multimon-ng randomly skips EAS headers or EOMs while processing a recorded audio. In general, multimon-ng with elevated verbose mode switch (e.g. -v 1) properly indicates every single header or EOM. However, from time to time it skips just one header or EOM code, like in the following example:

EAS (part): ZCZC-EAS-RWT-012057-012081-012101-012103-012115+0030-2780415-WTSP/TV-
EAS (part): ZCZC-EAS-RWT-012057-012081-012101-012103-012115+0030-2780415-WTSP/TV-
EAS (part): ZCZC-EAS-RWT-012057-012081-012101-012103-012115+0030-2780415-WTSP/TV-
EAS: NNNN
EAS: NNNN
EAS: NNNN
EAS (part): ZCZC-EAS-RWT-012057-012081-012101-012103-012115+0030-2780415-WTSP/TV-
EAS (part): ZCZC-EAS-RWT-012057-012081-012101-012103-012115+0030-2780415-WTSP/TV-
EAS: NNNN
EAS: NNNN
EAS: NNNN

I verified that the source audio file actually contained the skipped header; moreover, another run of the same audio file through the multimon-ng will likely end up with that "missing" header being detected and another one skipped in a random fashion. Is there something that can be done to fix that behavior?

EliasOenal commented 6 years ago

Regarding the random behaviour, could you convert your recording to "raw" and try again? (e.g. sox -t wav sample.wav -esigned-integer -b16 -r 22050 -t raw) multimon-ng internally uses sox for type conversion and we had similar behaviour with sox applying random dithering before.

abirger commented 6 years ago

I recorded audio with Audacity, and then exported it in both WAV and RAW format. And then I ran it through multimon-ng using the following command:

multimon-ng -v 1 -r -t raw -a EAS audiofile.raw

Actually, I tried many variations - feeding "multimon-ng" in real time with "arecord" and "rec" on Raspberry Pi with and without "sox" conversion and various buffering, recording with Audacity on Windows machine, and then processing the recorded audio - the result was more or less the same: random loss of codes...

EliasOenal commented 6 years ago

This indeed sounds like a bug in the EAS decoder then. I just wanted to make sure since back when I tried debugging a similar issue with POCSAG it turned out to be the sox resampling.

abirger commented 6 years ago

@EliasOenal , I noticed a pretty strange thing the last time I tested multimon-ng. I have a multi-hour record of the incoming audio that I've done on a Windows laptop in a raw format. Being fed to the decoder it produces multiple random code dropouts regardless of the multimon-ng version (I tried all from 1.1.1 to 1.1.4) and the test computer (Windows with older version or Raspberrypi with the newest one). The very first error seemed to show up consistently at the same time in about 3.5 min from the start (tried several times). With Audacity, I found and closely examined the EAS code instance that was dropped by decoder; it was in place and I could not notice any difference from the adjacent codes. For convenience, I carved out just the first 13 min of the record with Audacity, and the error was still there. However, when I cut it further to 5 min, the error stopped showing up. There is absolutely no difference between 5 min file and 13 min one (except for the length of course); I inverted one and merged it with another, and I got zero all the way through the length of the shorter file. I have no clue why it happened...

abirger commented 6 years ago

Found one error in demod_eas.c: in static char eas_allowed(char data), instead of if (data >= 32 || data <= 126) must be if (data >= 32 && data <= 126); otherwise, absolutely any symbol is allowed. That replacement helps to decrease the number of missed codes; however, does not seem to completely eliminate the issue.