Files from Audiomoth not being recognised #900
-
Good evening! Im attempting to train a CNN in Google Colab, and have successfully completed the whole process with your tutorial files. Ive now attempted to create a CNN using my own files and species. However, when I load in four example files I get this error: 11 frames /usr/local/lib/python3.10/dist-packages/soundfile.py in init(self, file, verbose) /usr/local/lib/python3.10/dist-packages/soundfile.py in init(self, file, mode, samplerate, channels, subtype, endian, format, closefd) /usr/local/lib/python3.10/dist-packages/soundfile.py in _open(self, file, mode_int, closefd) LibsndfileError: Error opening '/content/drive/My Drive/InputMother/WavFiles/20210907_130100.wav': System error. During handling of the above exception, another exception occurred: FileNotFoundError Traceback (most recent call last) /usr/local/lib/python3.10/dist-packages/librosa/core/audio.py in get_duration(y, sr, S, n_fft, hop_length, center, path, filename) /usr/local/lib/python3.10/dist-packages/audioread/init.py in audio_open(path, backends) /usr/local/lib/python3.10/dist-packages/audioread/rawread.py in init(self, filename) FileNotFoundError: [Errno 2] No such file or directory: '/content/drive/My Drive/InputMother/WavFiles/20210907_130100.wav' The above exception was the direct cause of the following exception: GetDurationError Traceback (most recent call last) /usr/local/lib/python3.10/dist-packages/opensoundscape/utils.py in make_clip_df(files, clip_duration, clip_overlap, final_clip, return_invalid_samples, raise_exceptions) GetDurationError: Exception on file /content/drive/My Drive/InputMother/WavFiles/20210907_130100.wav The above exception was the direct cause of the following exception: GetDurationError Traceback (most recent call last) /usr/local/lib/python3.10/dist-packages/opensoundscape/annotations.py in one_hot_clip_labels(self, clip_duration, clip_overlap, min_label_overlap, min_label_fraction, full_duration, class_subset, final_clip, audio_files) Deleting all the audiomoth files from the input folder, leaving just a file made by Batlogger, solves the issue.... so it cannot be a problem with file path or storage. All labels were produced in the same way with Raven, and none of the files were corrupted. Have searched online for solutions, including force updating soundfile. Providing .wav files from non-audiomoth devices works fine. Am I missing something, or is this a new issue? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
Interesting, I'm not sure why audiomoth files would cause any issues compared to Batlogger files. Are you able to open those AudioMoth files on a computer? (ie, they are not corrupted or they don't have 0 length for some reason) You can check if CoLab can see your audiomoth file like this:
which should also give you the size of the file. If you are able to open the file and colab finds the file with the command above, please also try loading the file into an OpenSoundscape Audio object: from opensoundscape import Audio
myaudio = Audio.from_file('/content/drive/My Drive/InputMother/WavFiles/20210907_130100.wav')
myaudio This error does suggest the file is not accessible or cannot be opened, so I wonder if there's something specific about these files and colab that is causing an issue. If you can share the file size of the AudioMoth files that could also be a clue. Finally, are you using the "triggering" feature on AudioMoths to only record based on an amplitude or frequency trigger? If so, could you share an audio file (private via email is also ok)? We don't typically use that feature, so it could be that the formatting of the AudioMoth file causes this issue. |
Beta Was this translation helpful? Give feedback.
-
I finally identified the problem, and I feel like an absolute idiot. My audiomoth files had the extension .WAV when they should have had .wav (lowercase). When I corrected that, they loaded correctly. Now, however, Im having a different issue (this time with creating annotation). Basically, when it reads my selection tables it is mixing up the columns - it isn't recognising my actual Annotation column as containing anything, and instead assigns a string of numbers to it. Im not sure what is causing this, as Ive tried importing selection tables from Raven with the default column headers ("Annotation" for the species names) and also tried with "Species" as the column name (as in your tutorial data) It is probably, once again, an issue with the input files, because your tutorial data works perfectly. But I cannot figure it out what is causing it or how to fix it. Have you heard of a similar issue? For reference, have attached my code and some example input data. |
Beta Was this translation helpful? Give feedback.
-
The default behavior is to guess the annotation column based on the column position (8th column), which can be buggy but at least works for the default column names in both Raven Pro and Raven Lite. If you specify the name of the column with your annotations it works properly: See the documentation for details: https://opensoundscape.org/en/latest/api/modules.html#opensoundscape.annotations.BoxedAnnotations.from_raven_files |
Beta Was this translation helpful? Give feedback.
The default behavior is to guess the annotation column based on the column position (8th column), which can be buggy but at least works for the default column names in both Raven Pro and Raven Lite. If you specify the name of the column with your annotations it works properly:
BoxedAnnotations.from_raven_files(....,annotation_column_name='Annotation')
See the documentation for details: https://opensoundscape.org/en/latest/api/modules.html#opensoundscape.annotations.BoxedAnnotations.from_raven_files