I would like to be able to write PCM wav files with 32-bit floating point samples. This seems to be a valid format since libsndfile claims to support it.
However, if I specify in my header a sample size of 32-bits, any program I open it in assumes that it's 32-bit integer data. What flags, etc need to be set in the wav file header to specify floating point data?
Can anyone point me to some documentation that explains how to do this?
You need to set the wFormat tag in the 'fmt' chunk to WAVE_FORMAT_IEEE_FLOAT (3).
A good source for the WAVE format specification is this page.
Related
My output (csv/json) from my newly-created program (using .NET framework 4.6) need to be converted to a IBM-1027-codepage-binary-file (to be imported to Japanese client's IBM mainframe),
I've search the internet and know that Microsoft doesn't have equivalent to IBM-1027 code page.
So how could I output a IBM-1027-codepage-binary-file if I have an UTF-8 CSV/json file in my hand?
I'm asking around for other solutions, but for now, I think I'm going to have to suggest you do the conversion manually; I assume whichever language you're using allows you to do a hex conversion, at worst. For mainframes, the codepage is usually implicit in the dataset, it isn't something that is included in the file header.
So, what you can do is build a conversion table, from https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/reference/html/hcp_reference26.htm. Grab a character from your json/csv file, convert to the appropriate hex digits, and write those hex digits to a file. Repeat until EOF. (Note to actually write the hex data, not the ascii representation of the hex data.) Make sure that when the client transfers the file to their system, they perform a binary transfer.
If you wanted to get more complicated than that, you could look at enhancing/overriding part of the converter to CP500, which does exist on Microsoft Windows. One of the design points for EBCDIC was to make doing character conversions as simple as possible, so many of the CP500 characters hex representations are the same as the CP1027, with the exception of the Kanji characters.
This is a separate answer, from a colleague; I don't have the ability to validate it, I'm afraid.
transfer the file to the host in raw mode, just tag it as ccsid 1208
(edited)
for uss export _BPXK_AUTOCVT=ALL
oedit/obrowse handles it automatically.
sorry for this not being a programming question directly, but more indirectly as i try to batch convert audio files, which is proving difficult.
I have an audio file which i exported from a package. This audio file is of the RIFF WAVE format. As far as i have read up on headers, normal headers are 44 bytes long. Which contains the sub parts "fmt " and "data". However, this header shows all kind of weird junk, which i cannot actually place anywhere.
If anyone is an audio guru of sorts, please help me out on how to make this audio file accessible for most audio players? i do not care to lose some of the header data as long as it plays the actual content.
Here is a screenshot of my current header data unaltered:
Thanks in advance.
44Bytes is the size of a minimal Wav File header. The format allows for other data chunks in the header in addition to the Riff, fmt and data chunks.
It looks like you have some cue information in your file. This is not a problem, most audio players should accept a wav file with these chunks.
How to write cues/markers to a WAV file in .NET discusses how to add a cue chunk to a file.
http://www.sonicspot.com/guide/wavefiles.html covers some of the additional chunks a wav file can have.
Mike
Turns out this WAVE thing is just a container, and it actually contains a .ogg. I used ww2ogg 3rd party tool to get out these .ogg files as wave. Thanks for all the help though!
According to http://en.wikipedia.org/wiki/WAV there is a table of wave files with different comperssion. You can just investigate in HEX editor a value of AudioFormat field of fmt chunk, to get a list of most common codecs used for compression.
i am wondering if there is any way to cycle through a .wav file to get the amplitude/DB of a specific point in the wav file. i am reading it into a byte array now but that has no help to me from what i can see.
i am using this in conjunction with some hardware i have developed that encodes light data into binary and outputs audio. i wont get into the details but i need to be able to do this in c# or c++. i cant find any info on this anywhere. i have never programmed anything relating to audio so excuse me if this is a very easy thing.
i dont have anything started since this is the starting point so if anybody can point me to some functions, libraries, or methods to being able to collect the amplitude of the wave at a specific time in the file, i would greatly appreciate it.
i hope this is enough info, and thank you in advance if you are kind enough to help.
It is possible and it is done in a straightforward way: the file with PCM audio contains one value for every channel, for every (1/sample-rate) of second.
The values however might vary: 8-bit, 16-bit, single precision floating point values. You certainly have to take this into account and this is the reason you cannot take the bytes from byte array directly.
The .WAV file also has a header preceding the actual payload.
I have a rather different question. So I'm using Matlab on a Linux Gentoo machine. I got a few Asus Xonar STX soundcards, and I'm trying to use them as sensitive audio frequency analyzer using the PlayRec non blocking audio IO package.
Now I know that Matlab will say if you try to use the audiorecorder function, and specify 24 bits in linux, it will tell you that 24bit is only supported in Windows. However the ALSA literature does not imply that this is a limitation of the operating system or of ALSA itself, and as a matter of fact Alsa seems to allow you to specify a 24 bit PCM device. And PlayRec uses PortAudio, which then uses Alsa on Linux systems.
Now this is all well and good, and Playrec doesn't seem to have a means of specifying the bit depth, just the sample rate. I have run many tests and know what the transfer function of my soundcard is (floating point return value to input Voltage conversion ratio), and I know my peak voltage is 3V, and my noise is around 100uV. This gives me 20*log10(3/100e-6) = 91dB. Which is closer to what I expect to see from 16 bits and not from 24.
My real question is this: Is there some way of verifying that I am in fact getting 24 bits in my captured signal?
And if I am not, is there some inherent limitation of ALSA or Matlab which is restricting me to only 16-bit data from sound capture devices, even when using 3rd party program to gather that data.
If you observe the data that playrec is putting out through playrec('getRec', ...), you'll see that it always is single-precision floating point (tested on Windows, MATLAB R2013b, most current Playrec). (you can verify it yourself after recording a single page with Playrec and looking in the workspace window of the IDE or by running whos('<variable_name_of_page>') at the command line.
If you look at Line 50 of pa_dll_playrec.h, you'll see that single-precision is chosen by definition:
/* Format to be used for samples with PortAudio = 32bit */
typedef float SAMPLE;
Unfortunately, this does not completely answer the question of exact sample precision, because the PortAudio lib converts samples from the APIs varying in format into the defined one. So if you want to know, what precision you're actually getting, I'd suggest a very pragmatic solution: looking at the mantissa of the 32-bit floating sample values. A simple fprintf('%+.32f\n', data) should suffice to find out how many decimal places are actually used.
Edit: I just realized I got it wrong. But here's the trick: Record audio off of an empty channel of your audio device. Plot the recorded data and zoom into the noise floor. If you're just getting plain zeros, the device is probably not activated properly (or has a too good signal/noise ratio). Try an external interface and/or turn up the gain a little bit). Depending on the actual bit resolution of the recorded data, you'll see quantization steps in the samples. Depending on the bit-depth originally used by the quantizer, those steps are bigger or smaller. Below you'll see the comparison between 16-bit (left) and 24-bit (right) of to seperately recorded blocks, from the same audio device, only that I used PortAudio's WASAPI API (on Windows, obviously) on the left and ASIO on the right:
The difference is quite obvious: at these very low levels, 16-bit only allows three values, while 24-bit has much finer stepping. So this should be a sufficient answer to your question on how to determine the real bitdepth and if your signal is recorded at 24-bit. If there are sample steps smaller than 2^-15, the odds are pretty good.
Looking in to this topic made me realize that it very much depends on the API of the currently chosen recording device, which bit-depth the quantization actually happens at. ASIO seems to always use 24-bit, while for example WASAPI falls back to 16-bit.
If you can store that signal as a wav file, run a file command on the wav from the command line in linux. Something like:
file x.wav will give you sampling rate and bits that the file was encoded at. The output is usually something like: 16 bit, 16000Hz etc.
Does all audio format has a header for audio length (in second)?
If not, what kind of audio format has that information embedded in the header.
Thank you.
Not necessarily. Typical wav files will have a wave format chunk (WAVEFORMATEX if you're coding on Windows) which contains the sample rate and number of bits per sample. Most of the WAV files you'll tend to come across are in PCM format where you know that there is always the same number of samples per second and bits per sample, so from the size of the file and these values you can work out the duration exactly.
There are other types of WAV file though which may be compressed (though these are much rarer) and for those you'll need to use the 'average bytes/sec' field of the WAVE header to work out the length.
If you're using AIFF (largely used on macs) then this has similar data members in the header.
Getting the length from an MP3 file is more difficult -- some suggestions are in this other question