zlacker

[parent] [thread] 12 comments
1. lunixb+(OP)[view] [source] 2020-06-08 23:26:48
I prototyped this concept too, at https://feeds.talonvoice.com with prohibitively expensive Google speech recognition, but also have a feature for users to listen and fix transcriptions. If murph was anything like me they probably paid for broadcastify and tailed a couple of the static mp3 feeds.

My plan was to collect user transcription corrections on my site then train my own inexpensive models on them. The open-source speech tech I work on can do passable transcription at close to 100x faster than realtime on a quad core desktop CPU (or 200 simultaneous streams per 4-core box at 50% activity). With higher quality transcription it's closer to 10-20x faster than realtime.

For your case you could also try to push some of the computation down to the uploading machine. These models can run on a raspberry pi.

I think the biggest work for a new effort here is going to be building local language models and collecting transcribed audio to train on. However, there have been a couple of incredible advances in the last year for semi-supervised speech recognition learning, where we can probably leverage your 1 year backlog as "unsupervised training data" while only having a small portion of it properly transcribed.

The current state-of-the-art paper uses around 100 hours of transcribed audio and 60,000 hours of unlabeled audio, and I bet you could push the 100h requirement down with a good language model and mixing in existing training data from non-radio sources.

replies(4): >>blanto+a1 >>jcims+M5 >>optimu+Pm >>runawa+kt
2. blanto+a1[view] [source] 2020-06-08 23:34:39
>>lunixb+(OP)
Our new project, Broadcastify Calls, might be a better fit for this. Instead of 24x7 live streams, we capture and ingest every individual call as a compressed audio file from SDRs (software defined receivers) We can then ingest and present back to consumers playback, rewind, playlist, of those calls. We're now capturing over 100 systems and 800-900 calls a minute... as we solidify the architecture it will be our new direction for how we capture and disseminate public safety audio (Police Scanners)

https://www.broadcastify.com/calls

replies(3): >>lunixb+J1 >>p0sixl+s2 >>jcims+T6
◧◩
3. lunixb+J1[view] [source] [discussion] 2020-06-08 23:39:58
>>blanto+a1
The source repo to feeds.talonvoice.com includes a test ingestor that scrapes your calls API and uploads the src/dst info with the transcription, I haven't tested it live though.
◧◩
4. p0sixl+s2[view] [source] [discussion] 2020-06-08 23:45:31
>>blanto+a1
Hey Blatoni, big fan, and software engineer here. Any way you could add Rochester, NY (Monroe County Sheriff, and RPD) to the list of supported calls? I have an RTL SDR, but haven't been able to spend the time figuring out how to decrypt the Phase II trunking.
replies(2): >>blanto+73 >>robota+gZ
◧◩◪
5. blanto+73[view] [source] [discussion] 2020-06-08 23:50:52
>>p0sixl+s2
You can get started as a calls ingest provider here:

https://wiki.radioreference.com/index.php/Broadcastify-Calls

6. jcims+M5[view] [source] 2020-06-09 00:16:13
>>lunixb+(OP)
Not to be 'that guy' but I vastly prefer your implementation. Having both the audio and transcription is almost mandatory to something like this (unless I'm an idiot and missing the ability to play the call on this).

I wonder if one could mix in openstreetmap data for a location to help pick up local references. (Eventually would be cool to round trip it with a little ping when addresses/businesses are referenced).

replies(1): >>lunixb+0d
◧◩
7. jcims+T6[view] [source] [discussion] 2020-06-09 00:29:11
>>blanto+a1
Love the idea! P25 decoder seems like it needs a little tuning...can you share what you're using?

Any thoughts on adding the ability to comment/transcribe/etc?

◧◩
8. lunixb+0d[view] [source] [discussion] 2020-06-09 01:32:07
>>jcims+M5
Yes, I think local language modeling would be crucial to doing this correctly
9. optimu+Pm[view] [source] 2020-06-09 03:19:25
>>lunixb+(OP)
Hi lunixbochs!

Your prototype is amazing! The quality of transcription is definitely better than ours via Google.

After we did some legal research we wanted to avoid storing the recordings and rather solely transcription text. Giving access to a platform for humans to verify the transcriptions and in turn train the model is a great idea.

I have started working on getting some pre-trained models set up. I am trying to implement them with wav2letter, deepspeech, kaldi, vosk, etc. - I just need to be pointed in the right direction.

Raspberry Pi's were something I was considering as well - small energy footprint and powerful enough to run these models.

Do you have any advice on ML or acoustic models to avoid? I am working with the 100 hour dataset now.

Thanks!

replies(1): >>johann+2n1
10. runawa+kt[view] [source] 2020-06-09 04:45:23
>>lunixb+(OP)
I’d love to read a write up on this if you ever feel the urge.
◧◩◪
11. robota+gZ[view] [source] [discussion] 2020-06-09 11:42:14
>>p0sixl+s2
Hop on to https://gitter.im/trunk-recorder/Lobby if you are having trouble getting the https://github.com/robotastic/trunk-recorder software running. Trunk Recorder puts a wrapper around the OP25 software and lets you capture all of the audio from a radio system using an SDR.
◧◩
12. johann+2n1[view] [source] [discussion] 2020-06-09 14:57:53
>>optimu+Pm
I have the same setup as Broadcastify Calls (trunkrecorder) and a site built to play each audio recording then allow the user to provide what they heard. I used it to train some public safety specific models on Kaldi and Sphinx.

I have 30ish streams and keep 6 days worth, I could keep longer if you'd like to work together on this. I reached out to some of the people above, the Broadcastify guy for example, and they are, as mentioned, ready doing their own thing so didn't really care about what I wanted to share.

replies(1): >>robota+aQ2
◧◩◪
13. robota+aQ2[view] [source] [discussion] 2020-06-10 01:17:15
>>johann+2n1
This sounds awesome - If you have any documentation up on how to do this, I would love to point to it from the trunk-recorder wiki.
[go to top]