KejPi
CLI support: help needed
I would love to see AbracaDABra support CLI usage, so that expert users can use it without GUI.
For example it would be great to launch the app like this:
abracadabra-cli -c 6D -d rtl_sdr
to record audio output or to export all the data from Ensemble Information window, so you can monitor the reception of a DAB signal.
I am quite capable of implementing it but I need some guidance on the actual codebase structure, so help would be appreciated
If we ever have that, I would be interested, that the audio is recorded in the same way as AbracaDABra can (uncompressed if needed, otherwise mp2 or AAC).
I am working on a fork for the CLI support
I need a lot of help from people more experienced with knowledge on how AbracaDABra works internally to handle measures, services and audio.
Current application code is not really ready for CLI mode, it was not designed for that use case. I am working on application redesign that could be better for that purpose when it is finished.
BTW
It would be the only tool for the console. There are two for listening, but non allows recording in AAC.
Current application code is not really ready for CLI mode, it was not designed for that use case. I am working on application redesign that could be better for that purpose when it is finished.
Do you have an ETA for the new redesign of the app? It would be a waste of time for me to try to get the actual version to work from CLI if a new and improved version will be coming soon.
I would be proud to contribute to your work
I would like to release first redesigned version before end of the year, it depends on time I have to work on it.
AOL! AOL! AOL! (in case you remember that joke from the early days of the internet)
I'd also be very interested in adding some command-line parameters to the program - or for a new CLI-version. I'm particularly interested in extracting a service's audio from a pre-recorded RAW-file as fast as possible - not just in "real time", like in the video below. It simply wastes a lot of time.
The suggested command-line parameters might look like this:
"-rawin" The path/filename of a RAW-recording used as source
"-sid" The service ID of the desired service in hex format, e.g., 0xd210
"-aout" The path to an (existing) folder where the extracted audio file should be saved.
The filename is created by the program as usual and looks something like this: "2025-09-08-101723_E0D210_Dlf.wav" The date and time stamp in the generated filename should, however, come from the multiplex (converted to the local time using the LTO offset) and not from the current system time at the users computer.
"-audfo" Specifies the wanted recording format ("WAV" or "AAC").
In every case the program should disable the "file-looping"-switch. Otherwise the program don't stop the audio-recording after EOF. It's a good idea, too, to save the "DL+" stuff. It's only text and makes it possible to find a track inside of the audio-recording, later.
As you can see in the video, multiple instances of the program can be started without problems for the system. Therefore, it is not necessary to define a "catch all" option, such as "all" (for all services in the multiplex), for the "-sid" option.
Just a little more information about the video. The sound, which remembers a little bit to the beginning of the film "Contact", is enabled here "just for the show". If the instances are started relatively quickly one after the other, the RAW-file used is only read once. The operating system provides the IQ-data for subsequent instances from the file cache, because the system knows that some programs wants to read from the same file. If you look in the Task Manager, only 4 MB/s are being read from the hard drive.
Have a nice time Heiko
https://github.com/user-attachments/assets/cd52b303-fd4e-484a-aa73-e46cbd1d7a91
@KejPi any updates on estimated ETA of the redesign? I can provide help whenerever it comes out to implement the CLI support
No update, it is progressing slowly, I do not have much time to work on that :-(