I am trying to convert a raw file (header-less) to wav
It is in ADPCM 16 rate 8000
I have tried three console commands
sox -e ima-adpcm -r 8000 input.raw output.wav
sox -e ima-adpcm -r 8000 -b 16 input.raw output.wav
These trigger the same error:
sox FAIL formats: bad input format for file `input.raw': data encoding or sample size was not specified
and last attempt
sox -t raw -t wav -e ima-adpcm -r 8000 -b 16 input.raw output.wav
which triggers another error
sox FAIL formats: can't open input file `input.raw': WAVE: RIFF header not found
Do you know why I get these errors?
Thanks
EDIT
An hex dump of the first 48 bytes FYI
C0 0C 00 03 00 00 37 C0 34 0C D0 30 37 C0 30 C7 CD D3 C0 03 CD 00 37 03
C0 00 0D 0C CD 00 C0 10 0F 00 03 55 0B 4B 0F 0F 0C 0F 34 0F 0D C3 0D 03
00 C0 31 00 00 D0 C0 00 F4 4C 03 33 34 33 31 33 0D 33 D0 03 C0 4C C0 43
Looks like using -t raw -e ima-adpcm doesn't work, but rather you have to use -t ima -e ima-adpcm.
I guess -t raw means raw PCM, whereas -t ima means raw ADPCM?
This worked for me to convert an ADPCM file into .wav:
sox -t ima -r 44100 -e ima-adpcm in.raw -e signed-integer -b 16 out.wav
The file extension doesn't seem to matter as long as you indicate ADPCM with -t ima.
Can you change the filename from input.raw to input.ima ? If you can, then
sox input.ima -r 8000 -b 16 output.wav
ought to work. .raw seems to be a magic extension for sox and it assumes certain possibilities for the data. See this man page.
Related
I'm trying to get every new line with tail from a file and transform it to hexdump, but I'm unable to write it to a file, I've tried with >> and | tee -a destfile but it doesn't give any error but stops working.
So, I have a binary file (data.bin) that is always growing new lines with a script.I'm trying to read and transform it to hexadecimal, that works well, and it outputs well:
tail -f data.bin | hexdump -e '16/1 "%02x " "\n"'
this outputs this:
01 55 1d fa 14 ae b5 41 ec 51 3c 42 64 55 00 00
74 5e f7 5d 00 00 00 00 02 55 1d fa 33 33 b3 41
7b 14 3f 42 63 55 00 00 74 5e f7 5d 00 00 00 00
When I try to do this
tail -f data.bin | hexdump -e '16/1 "%02x " "\n"' >> destfile.txt
It creates an empty file and doesn't write anything.
When you redirect the output of a command, the output stream becomes fully buffered, so it will not be visible until flushed. You could read for exaple this link for more information.
To make the output line buffered you can use stdbuf utility from GNU coreutils:
stdbuf -oL tail -f input | stdbuf -oL hexdump -e '16/1 "%02x " "\n"' >> destfile.txt
That way the output will be flushed each line.
I am currently looking at online examples and here is a WAV file contents in bytes
52 49 46 46 24 08 00 00 57 41 56 45 66 6d 74 20 10 00 00 00 01 00 02 00
22 56 00 00 88 58 01 00 04 00 10 00 64 61 74 61 00 08 00 00 00 00 00 00
24 17 1e f3 3c 13 3c 14 16 f9 18 f9 34 e7 23 a6 3c f2 24 f2 11 ce 1a 0d
and here is the visual; representation:
So according to the Subchunk2Size there is 2048 bytes in the data. The formula to calculate the number of samples in a WAV is given as:
Subchunk2Size /(NumChannels * BitsPerSample/8 ) = NumSamples
If I plugin numbers and according to the information given I get NumSamples = 512. But in the diagram the sample rate is 22050. How can the total number fo samples be less than a single second of samples?
For those wondering, here is a link to the source.
I suspect they are just using a bad example where the duration of the wav file would be less than a second. Their formula makes sense and we can use it to verify the data size of a one second wav file.
If our sample rate is 22050 samples/sec and our wav file is one second, then numSamples = 22050. We know that Subchunk2Size is the number of bytes in the data and can be calculated using this formula: Subchunk2Size = numSamples * numChannels * bitsPerSample / 8 , so, assuming numChannels = 2 and bitsPerSample = 16, we know that a one second wav file should be (22050 * 2 * 16 / 8) bytes which is 88200 bytes, so it would make sense that if Subchunk2Size is 2048 bytes, as per the website's example, then the duration of the wav file would be less than a second and thus, numSamples would be less than 22050.
If i have a packet capture in the below text format, which is a cli packet capture in fortigate or fortimail
FortiMail # diag sniffer packet port1 'tcp port 443' 3
interfaces=[port1]
filters=[tcp port 443]
10.651905 192.168.0.1.50242 -> 192.168.0.2.443: syn 761714898
0x0000 0009 0f09 0001 0009 0f89 2914 0800 4500 ..........)...E.
0x0010 003c 73d1 4000 4006 3bc6 d157 fede ac16 .<s.#.#.;..W....
0x0020 0ed8 c442 01bb 2d66 d8d2 0000 0000 a002 ...B..-f........
0x0030 16d0 4f72 0000 0204 05b4 0402 080a 03ab ..Or............
0x0040 86bb 0000 0000 0103 0303 ..........
how to convert it to this format, to be able to use text2pcap to convert it to pcap. So could be easily opened in wireshark.
FortiMail # diag sniffer packet port1 'tcp port 443' 3
interfaces=[port1]
filters=[tcp port 443]
10.651905 192.168.0.1.50242 -> 192.168.0.2.443: syn 761714898
0000 00 09 0f 09 00 01 00 09 0f 89 29 14 08 00 45 00 ..........)...E.
0010 00 3c 73 d1 40 00 40 06 3b c6 d1 57 fe de ac 16 .<s.#.#.;..W....
0020 0e d8 c4 42 01 bb 2d 66 d8 d2 00 00 00 00 a0 02 ...B..-f........
0030 16 d0 4f 72 00 00 02 04 05 b4 04 02 08 0a 03 ab ..Or............
0040 86 bb 00 00 00 00 01 03 03 03 ..........
A very similar question was asked and answered on the old Wireshark Ask Q&A site. Here's a link to that question with my answer posted verbatim below for convenience:
Yes, you can use text2pcap to convert it to a pcap file, but you will first need to massage the data into a format that text2pcap accepts, because the depicted format is currently not supported by text2pcap.
So first, you can convert the data into a suitable format by using Kurt Knochner's perl script, given as an answer to this question and copied here for convenience:
#!/usr/bin/perl
$| = 1;
my $regexp_time = '(\d\d:\d\d:\d\d\.\d+ )';
my $regexp_hex = '(0x\d+:\s+)([0-9a-f ]+)+ ';
while (<STDIN>) {
my $input = $_;
if ($input =~ /^$regexp_time/) {
print "$1\n";
}
if ($input =~ /$regexp_hex/) {
my $counter = $1;
my $line = $2;
$line =~ s/ //g;
$counter =~ s/(0x|:)//g;
print $counter . join(' ', ( $line =~ m/../g )) . "\n";
}
}
Assuming the output of tcpdump is saved in a file called, tcpdump.txt, and Kurt's perl script is saved as convert.pl, run:
cat tcpdump.txt | convert.pl > tcpdump_converted.txt
Once that's done, run text2pcap on the converted file:
text2pcap -l 101 tcpdump_converted.txt tcpdump_converted.pcap
Note that here I'm specifying "Raw IP" encapsulation. See http://www.tcpdump.org/linktypes.html for link types.
I realize your output wasn't generated from tcpdump, so the script may not work exactly as is in your case, but it shouldn't be too difficult to tailor it to meet your needs if it doesn't do what you need it to do out of the box.
I solved the issue by 2 VIM replace commands
this one to replace all 4 digit hex to 2 digit hex
%s/\s\([0-9a-f]\{2}\)\([0-9a-f]\{2}\)/ \1 \2 /g
and this one to remove 0x from the beginning of the line
%s/^0x//
Then run:
text2pcap in-mod.txt out.pcap
I would like to echo an array of bytes from the linux terminal to serial port. Have already seen this Sending bytes to serial port from UNIX command line? and from that deduced the command will be something like the following:
printf '%b' '\x9c8684a4624000a0b2668a84400003f00301000000048ab0c0' > /dev/ttyUSB0
To debug the ideia I redirected it to a file with
printf '%b' '\x9c8684a4624000a0b2668a84400003f00301000000048ab0c0' > file.raw
and checked the file with hexedit. But so I've found that ASCII values were been written instead.
In the end I expect the following in the file:
9c 86 84 a4 62 40 00 a0 b2 66 8a 84 40 00 03 f0 03 01 00 00 00 04 8a b0 c0
I have a problem with my website, which is completely gzipped:
http://goout.cz/cs/fotoreporty/
The page can be easily shown in Chrome, but in Safari it never loads (and I suppose in other browsers as well. When I try:
curl -v http://goout.cz/cs/fotoreporty/ | gzip -d
I am getting expected results. But validation on
http://validator.w3.org/check?uri=http%3A%2F%2Fgoout.cz%2Fcs%2Ffotoreporty%2F#fatal-errors
yields:
The error was: Can't gunzip content: Header Error: Minimum header size is 10 bytes
What is wrong with the gzip format? How can I solve it? Thanks.
EDIT:
The gzip header seems to me okay to me:
$ curl http://goout.cz/cs/ | head -1 | hexdump | head -1
0000000 1f 8b 08 00 00 00 00 00 00 00 ed 5d cd 73 db 38
$ curl http://goout.cz/cs/fotoreporty/ | head -1 | hexdump | head -1
0000000 1f 8b 08 00 00 00 00 00 00 00 ed 7d cf 73 e3 46