This is great to hear! I just installed 25 AudioMoths and a couple of temperature data loggers. I will upgrade my firmware to get this new function and pass on the temp loggers! Thanks.
This is very helpful. I was able to open in Audacity and see metadata. I use Wildlife Acoustic's Kaleidoscope and wish there was a way to read the metadata in that program. It reads other data, but not the AudioMoth unit number. Thanks!
It's a powerful utility that takes a bit of getting used to for advanced usage - but if you just need to read metadata all you need to do is drop the file onto the exiftool icon on your desktop and a command window will open up containing all the available data.
It handles a huge range of file types - not just .wav
Alternatively you can open the wav file in a hex editor (partially open if it's a huge file). AudioMoth metadata is only 48 bytes from the beginning of the file.
@John Connock - I saw from a different post that you were having a difficult time viewing temperature info. If you haven't gotten it resolved, this post from@davidlee_malvern, it helped me out.
You can use Advanced Renamer to add the AudioMoth serial number to a batch of .wav filenames (not necessarily from the same device) using the <File Content:X:Y> tag, where X is the starting offset and Y the number of bytes to copy.
Your method will only work if the temperature is the last item in the comment. Unfortunately amplitude threshold and/or filtering metadata is appended if either is enabled.
A better solution is to use the Script method, using a regular expression to extract the temperature from the comment. Try the following code:
Metadata is saved in a LIST-INFO sub-chunk at the beginning of the wav file - just before the data chunk.
There are two meta-data fields saved:
1) Comments - ICMT: 256 byte field eg "Recorded at 20:54:00 31/07/2019 (UTC+1) by AudioMoth 240435045AA4EE39 at gain setting 2 while battery state was 4.2V."
2) Artist Name - IART: 32 byte field eg "AudioMoth 240435045AA4EE39"
This data can be read by Audio programs such as Audition and Audacity.
I've attached a document I prepared some years ago for my own reference detailing the basic structure of a .wav file that may be some help and there is a list of wav file chunks - including available native RIFF metadata fields - at http://www.robotplanet.dk/audio/wav_meta_data/
My document doesn't include the LIST-INFO sub-chunk but this is the format as I understand it:
LIST INFO Sub-chunk:
Bytes 0 - 3: ASCII “LIST”
Bytes 4 - 7: Length of LIST sub-chunk (from Byte 8)
Bytes 8 - 11: List type - ASCII "INFO" (other list types are available)
Followed by available metadata fields - for each one:
Bytes 0 - 3: Field name (eg ICMT, IART)
Bytes 4 - 7: Length of metadata field (from Byte 8)
Bytes 8 - end: Metadata
So - the structure of an AudioMoth Wav file is as follows:
Wave Chunk Format:
Bytes 0 - 3: ASCII “RIFF”
Bytes 4 - 7: Length of Wave Chunk (from Byte 8 to end of data)
Bytes 8 - 11: ASCII “WAVE”
Format Sub-chunk
Bytes 12 - 15: ASCII “fmt ” (byte 3 = SPACE)
Bytes 16 - 19: 0x10 - Length of Format sub-chunk (from Byte 20)
Bytes 20 - 21: 0x01 - Uncompressed PCM file
Bytes 22 - 23: 0x01 - One channel
Bytes 24 - 27: Sample rate (Samples per second)
Bytes 28 - 31: Byte rate (Bytes per second)
Bytes 32 - 33: 0x2 - 2 Bytes per sample
Bytes 34 - 35: 0x10 - 16 Bits per sample
LIST sub-chunk
Bytes 36 - 39: ASCII "LIST"
Bytes 40 - 43: Length of LIST sub-chunk (from Byte 44)
Bytes 44 - 47: ASCII "INFO" - List type
Bytes 48 - 51: ASCII "ICMT" - Comment metadata
Bytes 52 - 55: 0x100 - Length of ICMT field (256 Bytes from Byte 56)
Bytes 316 - 319: 0x20 - Length of IART field (32 Bytes from Byte 320)
Bytes 320 - 351: IART field (32 Bytes)
Data Sub-chunk:
Bytes 352 - 355: ASCII “data”
Bytes 356 - 359: Length of Data sub-chunk (from Byte 360) – number of bytes of data to read.
Bytes 360 - end: The sound data.
You need to be aware that the order of chunks is not fixed - so some applications (eg BatSound) may save metadata at the end of the file - and wav files can contain proprietary chunks (such as GUANO metadata). So it is safer in general to search for metadata by navigating the file chunk-by chunk until you arrive at the desired chunk name rather than hard-coding the offsets. All chunks are tagged with the number of bytes to skip in order to reach the next chunk, so an application can just ignore unrecognized or unwanted data until it reaches the next required chunk.
Thanks, I will give that a shot. Much appreciated.
This is great to hear! I just installed 25 AudioMoths and a couple of temperature data loggers. I will upgrade my firmware to get this new function and pass on the temp loggers! Thanks.
This is very helpful. I was able to open in Audacity and see metadata. I use Wildlife Acoustic's Kaleidoscope and wish there was a way to read the metadata in that program. It reads other data, but not the AudioMoth unit number. Thanks!
You can use Advanced Renamer to add the AudioMoth serial number to a batch of .wav filenames (not necessarily from the same device) using the <File Content:X:Y> tag, where X is the starting offset and Y the number of bytes to copy.
www.advancedrenamer.com
For example using the Add method and
Add: <File Content:320:26>-
At index: 0
will add "AudioMoth xxxxxxxxxxxxxxxx-" to the beginning of each filename
May be useful for somebody.
Metadata is saved in a LIST-INFO sub-chunk at the beginning of the wav file - just before the data chunk.
There are two meta-data fields saved:
1) Comments - ICMT: 256 byte field eg "Recorded at 20:54:00 31/07/2019 (UTC+1) by AudioMoth 240435045AA4EE39 at gain setting 2 while battery state was 4.2V."
2) Artist Name - IART: 32 byte field eg "AudioMoth 240435045AA4EE39"
This data can be read by Audio programs such as Audition and Audacity.
I've attached a document I prepared some years ago for my own reference detailing the basic structure of a .wav file that may be some help and there is a list of wav file chunks - including available native RIFF metadata fields - at http://www.robotplanet.dk/audio/wav_meta_data/
My document doesn't include the LIST-INFO sub-chunk but this is the format as I understand it:
LIST INFO Sub-chunk:
Bytes 0 - 3: ASCII “LIST”
Bytes 4 - 7: Length of LIST sub-chunk (from Byte 8)
Bytes 8 - 11: List type - ASCII "INFO" (other list types are available)
Followed by available metadata fields - for each one:
Bytes 0 - 3: Field name (eg ICMT, IART)
Bytes 4 - 7: Length of metadata field (from Byte 8)
Bytes 8 - end: Metadata
So - the structure of an AudioMoth Wav file is as follows:
Wave Chunk Format:
Bytes 0 - 3: ASCII “RIFF”
Bytes 4 - 7: Length of Wave Chunk (from Byte 8 to end of data)
Bytes 8 - 11: ASCII “WAVE”
Format Sub-chunk
Bytes 12 - 15: ASCII “fmt ” (byte 3 = SPACE)
Bytes 16 - 19: 0x10 - Length of Format sub-chunk (from Byte 20)
Bytes 20 - 21: 0x01 - Uncompressed PCM file
Bytes 22 - 23: 0x01 - One channel
Bytes 24 - 27: Sample rate (Samples per second)
Bytes 28 - 31: Byte rate (Bytes per second)
Bytes 32 - 33: 0x2 - 2 Bytes per sample
Bytes 34 - 35: 0x10 - 16 Bits per sample
LIST sub-chunk
Bytes 36 - 39: ASCII "LIST"
Bytes 40 - 43: Length of LIST sub-chunk (from Byte 44)
Bytes 44 - 47: ASCII "INFO" - List type
Bytes 48 - 51: ASCII "ICMT" - Comment metadata
Bytes 52 - 55: 0x100 - Length of ICMT field (256 Bytes from Byte 56)
Bytes 56 - 311: ICMT field (256 Bytes)
Bytes 312 - 315: ASCII "IART" - "Artist" metadata (AudioMoth s/no)
Bytes 316 - 319: 0x20 - Length of IART field (32 Bytes from Byte 320)
Bytes 320 - 351: IART field (32 Bytes)
Data Sub-chunk:
Bytes 352 - 355: ASCII “data”
Bytes 356 - 359: Length of Data sub-chunk (from Byte 360) – number of bytes of data to read.
Bytes 360 - end: The sound data.
You need to be aware that the order of chunks is not fixed - so some applications (eg BatSound) may save metadata at the end of the file - and wav files can contain proprietary chunks (such as GUANO metadata). So it is safer in general to search for metadata by navigating the file chunk-by chunk until you arrive at the desired chunk name rather than hard-coding the offsets. All chunks are tagged with the number of bytes to skip in order to reach the next chunk, so an application can just ignore unrecognized or unwanted data until it reaches the next required chunk.
Curious if any progress on this? It would be nice to have device ID stored as metadata in each file.