I am trying to convert a wav file into TETRA encoded file (https://en.wikipedia.org/wiki/Terrestrial_Trunked_Radio). Tetra is used by fire-fighters, it provides a radio-like voice.
I am trying to use the official tetra codec codes available at (https://www.etsi.org/deliver/etsi_en/300300_300399/30039502/01.03.01_60/) and we can easily compile it using the scripts available at https://github.com/sq5bpf/install-tetra-codec.
However, I am not able to figure out how to convert a wav file into tetra codec files using these files. I tried going through the documentation of the compiled files (ccoder, cdecoder, scoder, sdecoder).
I tried the following command -
tetra/bin/scoder input.wav serial_file synth_file
here serial_file and synth_file are the output files and have following documentation in the scoder.c file:
INPUT : - Description : speech file to be analyzed
- Format : binary file 16 bit-samples
240 samples per frame
serial_file : - Description : serial stream output file
- Format : binary file 16 bit-samples
each 16 bit-sample represents one encoded bit
138 (= 1 + 137) bits per frame
synth_file : - Description : local synthesis output file
- Format : binary file 16 bit-samples
For an input file of size 13M, I obtained serial_file and synth_file of size 8.0M and 16M. However, I thought since the wav file is getting converted into a walkie-talkie type signal the output file size will be alot smaller.
I want to clarify if:
I used the correct code to convert an input wav file into a tetra format output file.
can you please help me understand, what is serial_file and synth_file.
Thanks,
Ashish
synth_file is an internal computed parameters, you can ignore it.
serial_file is actual encoded data, you can use it in sdecoder.
traditionally ETSI code use very unefficent output format where instead of bits they output textual or expanded representation of those bits. I.e. instead of a bit they write a word of 16-bit where all the bits are 0 and the last one has information. They do it to interface with their transmission corruption test tools I presume.
So the actual length of the serial file should be 16 times smaller, so you converted 13Mb to 0.5Mb which is OK.
Related
I was given a file that seems to be encoded in UTF-8, but every byte that should start with 1 starts with 0.
E.g. in place where one would expect polish letter 'ę', encoded in UTF-8 as \o304\o231, there is \o104\o031. Or, in binary, there is 01000100:00011001 instead of 11000100:10011001.
I assume that this was not done on purpose by evil file creator who enjoys my headache, but rather is a result of some erroneous operations performed on a correct UTF-8 file.
The question is: what "reasonable" operations could be the cause? I have no idea how the file was created, probably it was exported by some unknown software, than could have been compressed, uploaded, copied & pasted, converted to another encoding etc.
I'll be greatful for any idea : )
Everything is stored as 0 1 in digital , binary format file or other format file
So when we are trying to open a Executive file with hex editor it could show all the random ASCII character that will be produced based on 7, 0 1 bits that randomly created that ( anything ) file because it is 0 1 at the storage, in memory.
So why it shows strange character that are not ASCII char?
A hex reader doesn't just parse 7 bit per 7 bit or 8 bit? it read some meta data in file and then read based on that?
Your hex editor is choosing to decode the bytes not as ASCII but as some other character encoding.
You are right the ASCII character set has 128 codepoints and the ASCII character encoding encodes them in single bytes in the range 0 to 127. Since bytes in an arbitrary file could range from 0 to 255 and the ASCII character set isn't used much for text files, decoding as ASCII wouldn't reveal as much information about potential text as a more likely character encoding and would reveal information about only half of the values of binary files.
A hex editor's job is to display and allow you to edit bytes. Additional presentations and editing capability are extra features. Many do present text, some allow search and replace of text. Some even work with other data formats such as decimal integers, multibyte integers, floating point, etc.
There is no text but encoded text. So, to support text, a hex editor—and any other program (including compilers)—must choose or allow you to choose a character encoding. For byte values that can't be decoded using that encoding, a dot or question mark is often substituted in the text display of a hex editor.
If you don't find which character encoding is used by your hex editor, you could test it by creating a file with byte values 0 to 255, see what it displays and match it against the many, many possibilities. It might be one that your operating system uses for your "default". In Windows cmd, go chcp; In Linux terminal, go locale.
I have created layout based on cobol copybook.
Layout snap-shot:
I tried to load data also selecting same layout, it gives me wrong result for some columns. I try using all binary numeric type.
CLASS-ORDER-EDGE
DIV-NO-EDG
OFFICE-NO-EDG
REG-AREA-NO-EDG
CITY-NO-EDG
COUNTY-NO-EDG
BILS-COUNT-EDG
REV-AMOUNT-EDG
USAGE-QTY-EDG
GAS-CCF-EDG
result snapshot
Input file can be find below attachment
enter link description here
or
https://drive.google.com/open?id=0B-whK3DXBRIGa0I0aE5SUHdMTDg
Expected output:
Related thread
Unpacking COMP-3 digit using Java
First Problem you have done an EBCDIC --> ascii conversion on the file !!!!
The EBCDIC --> ascii conversion will also try and convert binary fields as well as text.
For example:
Comp-3 value hex hex after Ascii conversion
400 x'400c' x'200c' x'40' is the ebcdic space character
it gets converted to the ascii
space character x'20'
You need to do binary transfer, keeping the file as ebcdic:
Check the file on the Mainframe if it has a RECFM=FB you can do a transfer
If the file is RECFM=VB make sure you transfer the RDW (Record Descriptor word) (or copy the VB file to a FB file on the mainframe).
Other points:
You will have to update RecordEditor/JRecord
The font will need to be ebcdic (cp037 for US ebcdic; for other lookup)
The FileStructure/FileOrganisation needs to change (Fixed length / VB)
Finally
BILS-Count-EDG is either 9 characters long or starts in column 85 (and is 8 bytes long).
You should include Xml in as text not copy a picture in.
In the RecordEditor if you Right click >>> Edit Record; it will show the fields as Value, Raw Text and Hex. That is useful for seeing what is going on
You do not seem to accept many answers; it is not relevant whether the answer solves your problem; it is whether the answer is correct answer for the question.
I have a camera that send me an xml file with some tags , including a tag that represents the image in base64 format. The image is in JPEG format.
For some reason the tag that represents the image it doesn't always have the same name (for a problem of the camera)
So to detect with certainty the tag that contains the image is correct i have to now one thing :
A JPEG image in base64 format ALWAYS start with /9j/ ?
Example :
data:image/jpeg;base64,-->/9j/<--4RYQRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAgAAAAcgEyAAIAAAAUAAAAkodpAAQAAAABAAAAqAAAANQACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNiAoTWFjaW50b3NoKQAyMDE2OjA4OjA1IDA5OjQ1OjA4AAAAAAOgAQADAAAAAf//AACgAgAEAAAAAQAAAPGgAwAEAAAAAQAAAFkAAAAAAAAABgEDAAMAAAABAAYAAAEaAAUAAAABAAABIgEbAA....
Jpeg file format (as many others) can be identified by magic number. For JPEG the magic number is ff d8 ff at offset 0. If you encode this to Base64, you'll always get /9j/.
Additional note: since Base64 converts group of 3 data bytes to 4 bytes (ASCII), this will work for any magic number with length and offset multiple of 3 bytes. If the length of magic number is not multiple of 3, the last group of 4 Base-64 encoded characters will change depending on the data immediately following the magic number.
https://en.wikipedia.org/wiki/JPEG
https://en.wikipedia.org/wiki/List_of_file_signatures
I have created an ach file which, in a text editor looks exactly like a valid ach file. When I open it in an ACH viewer tool I get an error saying that the first character must be 1. I found this in the NACHA file specs 'Picture: This is the type of bit the ACH system is expecting to see. A 9 indicates a numeric value and an X indicates an
alphabetic value. If you put a letter in a PIC 9 position, the system will reject the field. If you see a number in parentheses
after the X or 9, that indicates the number of characters in that field. For example 9(10) means that field contains 10
numeric characters.'
The first position in the file is supposed to have content 1 in Picture format of size 1. I don't understand what do I need to do to fix this?
I finally downloaded a Hex file explorer and saw that the valid ACH file and my file both had different first characters. I found out that the ACH file needs the data in the ASCII format. All I had to do was when I populated the ACH file with data, I converted the data to ASCII before writing it.