How can we distinguish between PCM and BWF format?
Is it necessary for BWF to have "bext" header?
I have some streams that don't have "bext" header but contains "JUNK" header... Are these files BWF files?
Thanks you.
The JUNK chunk is reserved space to allow a BWF file to be converted into an RF64 file on the fly if the size goes over 4GB. The JUNK chunk is the same size as a ds64 chunk, and will be replaced with a ds64 chunk if the conversion to RF64 is needed. Read more about it here.
My reading of the BWF spec is that you have to have a bext chunk for it to be a BWF.
As far as I know, a broadcast wave file will have the 'bext' header extension.
If a file does not have the 'bext' header extension, it will be a normal WAV/AIFF or whatever file.
Broadcast wave headers are used especially if you want to give a file more information about itself in the header which isn't to be seen immediately from its name.
For playing back, this info isn't necessary to know. Just if you want to show or search the meta information somehow.
PCM isn't a file format. All files that handle uncompressed data are PCM files.
Such as WAV/BWF, AIFF or SD2 for example.
With encoded files like MP3 or AAC you get the raw PCM values after decoding.
Yes. The 'bext' chunk is what distinguishes a BWF file from a wav file.
Some manufacturers actually use '.bwf' as a file extension but mostly the '.wav' extension will be used. It is only the presence of this chunk that makes the difference.
Other chunks can also be present and a well designed player will ignore chunks that it doesn't recognize.
Generally the 'data' chunk containing the audio data will be the last one in the file. However I have seen a few examples of other chunks, usually xml metadata, appearing after the 'data' chunk. This confuses some players.
For more information search for tech3285.pdf from the European Broadcasting Union website (tech.EBU.ch).
Related
I am writing my own Opus Ogg writer following these specifications: RFC7845 and RFC3533.
Currently, I am facing an issue that I believe is related to how I am setting the lacing values (segment table).
My current setup is to basically read (using an existing Ogg reader) an Ogg file with a single Opus track and put that Opus track in another Ogg file that I create using my own Ogg writer.
So I have a function that takes the Opus content of each page from the original Ogg file and put it in pages in my new Ogg file.
I am being able to create the file successfully, but when I try playing it on VLC, it shows the correct timestamp but it does not play any sound.
I noticed that the issue is being caused by the way my segment table (or lacing values) is set.
I am currently creating it by filling each segment with as much data as possible (i.e 255 bytes), and letting only the last segment have a size < 255. This seems to be the way that other implementations are doing it (see Rust implementation, C implementation).
However, when I inspect the lacing values for a page containing that Opus content in the original Ogg file, it is not filled with 255s. It's another combination of segment sizes that still sums up to the same page size, but that uses more segments (since it's not taking up the max segment size). When I try using the exact segments combination in the original file, the file plays on VLC successfully.
So that makes me conclude that the approach I am taking with creating as many 255-sized segments is incorrect. Does anyone have any idea how to properly set the lacing values?
I have several pcap files which captured by wireshark.
I collected that data from pcap file, payload data.
and saved it as file.
I tried to convert it to pcm data with this link
https://github.com/ToughmanL/EVS_CODEC
but it seems the data I collected is not EVS format.
please let me know how to get EVS codec from pcap file.
My understanding is that Stack Overflow is for programming questions, so here is an answer based on existing / example source code. First, in your screen cap Wireshark has found a commonly used form of EVS; the 61 byte packet payload length matches the EVS spec for 24400 bps primary mode, using compact format, which means (i) no ToC header byte in the payload, and (ii) only the payload size determines the bitrate. Second, to feed that to the 3GPP decoder you have to create a file with a MIME header and format, which is needed by the 3GPP reference program.
x86_mediatest.cpp (under the mediaTest folder in the Docker containers here) does this - it reads a pcap record-by-record, pulls out RTP payloads and writes them to a .cod file (coded format), including the MIME header. Running the 3GPP program on that file, with appropriate command line options then gives a PCM raw audio file you can convert to wav using sox, Audacity, Hypersignal, etc.
In x86_mediaTest.cpp, look for "if (pcap_extract) {". Also note the comment "If pcap RTP payloads are in CH (Compact Header) format, they are converted to FH (Header-Full) format by adding a ToC payload header byte". Which may explain why in your case, if you directly copied the compact header format payloads and fed them to the 3GPP decoder, it didn't work.
There is also a mediaMin program that will take the pcap on the command line and do the whole thing, generating a .wav file. You can use that for comparison and audio quality testing vs your code.
Disclaimer: I work for the company that created the mediaTest and mediaMin tools
I've written a script to "normalize" all my FLAC files by stripping unneeded tags, padding tracknumber/discnumber, removing pictures, etc. As part of the normalization process, my script re-compresses the FLAC file to level 8. Since re-compressing an already level-8 FLAC is pointless and time consuming, I want a way to know if the audio of the FLAC file has been changed since my last compression (I don't want to use file modification time because changing the metadata would change this as well). Is there an easy way to get the MD5 hash or something of the FLAC audio section so I can quickly check if it's been altered? Thanks!
I ended up using the python-audio-tools over at http://audiotools.sourceforge.net/. Here's the relevant code, for future reference:
track = audiotools.open('file.flac')
metadata = track.get_metadata()
raw_hash = metadata.get_block(audiotools.flac.Flac_STREAMINFO.BLOCK_ID).md5sum
print(audiotools.hex_string(raw_hash))
Can some one tell me the WAV file header information for A-Law and Mu-Law?
In short, the WAVE format is a RIFF specification for mutlimedia files, which uses "chunks" to store data. Similar to a type-length-value representation, each chunk contains information about its own type and length (the fields SubChunkID and SubChunkSize) before the rest of the data.The information about the audio compression is stored in the "fmt" chunk.
Read this and this for more information.
Is the endianness of format params guaranteed in RIFF WAV files? I have heard conflicting answers to this including references to a RIFX file format.
Yes.
If the file starts with RIFF, then it's little endian.
If it starts with FFIR or RIFX, then it's probably not.
Generally, supporting the WAV format means supporting RIFF files, although adding RIFX support should not prove difficult.
The AES31 specification for BWF (Broadcast Wave Format) references this specification for RIFF: http://www.tactilemedia.com/info/MCI_Control_Info.html
From this:
RIFF has a counterpart, RIFX, that is
used to define RIFF file formats that
use the Motorola integer byte-ordering
format rather than the Intel format. A
RIFX file is the same as a RIFF file,
except that the first four bytes are
'RIFX' instead of 'RIFF', and integer
byte ordering is represented in
Motorola format.
The KVR article you reference refers to the author's incorrect usage of int* on big-endian systems (Motorola PPC), which will retrieve byte-swapped values. Care is always necessary to handle byte-swapping correctly when writing cross-endian code.
If the zeroth byte of the file on disk is 'R', and the 3rd is 'F', you can be certain that the rest of the contents will be stored little endian.
RIFX is not widely used. Most big-endian RIFF implementations swap bytes to disk, and generate correct RIFF files.