rf64 audio files - Printable Version +- Python Forum (https://python-forum.io) +-- Forum: Python Coding (https://python-forum.io/forum-7.html) +--- Forum: General Coding Help (https://python-forum.io/forum-8.html) +--- Thread: rf64 audio files (/thread-18352.html) |
rf64 audio files - kerzol81 - May-14-2019 Hi, I got tons of rf64 audio files. I try to parse the meaning of each field from the header with not much success. here is the header of such file: Quote: struct FormatChunk5 // declare FormatChunk structure and a comparison to a regular wav: And this is how I tried to extract for instance the sample rate: import struct audio_file = open("audio.aac", 'rb') wavHeader = audio_file.read(38) HeaderFields = { 'chunkId': 0, 'sampleRate': 0 } HeaderFields['sampleRate'] = struct.unpack('<i', wavHeader[13:17]) print(wavHeader) print(HeaderFields) audio_file.close()My output is on a sample wav: Quote:b'\xff\xf9`@\x1f\x7f\xfc\x01.5\xa0\xd6Dq5\n\x01oQ?\x7f\xe2\x7f\xb7\xf5\xdc\xa4\x08\x10A\x02\x008\xbb\xc3\x8a/J' The documentation says that the sampleRate is an integer, which is 4 bytes, that's why I count from 13-17. I tried mapping different fields, but it never gives me back a normal sample rate. DO you guys have any working solution to parse these new type of wav's header? Thanks RE: rf64 audio files - buran - May-14-2019 could it be possible due to using struct.unpack() ?from the docs: Quote:struct.unpack(format, buffer) That's exactly what you get - single element tuple, so this should return just the first element struct.unpack('<i', wavHeader[13:17])[0] RE: rf64 audio files - kerzol81 - May-14-2019 ok, but it's not what I expect when I return the first element: IN: struct.unpack('<i', wavHeader[13:17])[0] OUT: 'sampleRate': 17446257} It is supposed to be 44100, 32000, 22100 etc RE: rf64 audio files - buran - May-14-2019 the output from struct.unpack() is tuple. If you don't get the correct/expected value I would guess you don't parse the correct chunk of data RE: rf64 audio files - kerzol81 - May-14-2019 Yes, But I scanned through segment of the 38 byte chunk, and never came out a human readable data... I guess there is a problem with endiannes and the integer sizes RE: rf64 audio files - buran - May-14-2019 (May-14-2019, 11:50 AM)kerzol81 Wrote: I guess there is a problem with endiannes and the integer sizesyes, maybe that's another possibility - wrong format string in the unpack() RE: rf64 audio files - kerzol81 - May-14-2019 Do you think that the sample rate starts at the 13th byte? RE: rf64 audio files - buran - May-14-2019 Sorry, I am not familiar with the format |