Deteksi peristiwa audio dengan Amazon Rekognition

Ketika kebanyakan orang berpikir untuk menggunakan pembelajaran mesin (ML) dengan data audio, kasus penggunaan yang biasanya muncul di benak adalah transkripsi, juga dikenal sebagai pidato-ke-teks. Namun, ada aplikasi lain yang berguna, termasuk menggunakan ML untuk mendeteksi suara.

Menggunakan perangkat lunak untuk mendeteksi suara disebut deteksi acara audio, dan memiliki sejumlah aplikasi. Misalnya, Anda ingin memantau suara dari lantai pabrik yang bising, mendengarkan bel alarm yang menunjukkan masalah dengan mesin. Di lingkungan perawatan kesehatan, Anda dapat menggunakan deteksi peristiwa audio untuk secara pasif mendengarkan suara dari pasien yang menunjukkan masalah kesehatan akut. Beban kerja media sangat cocok untuk teknik ini, misalnya untuk mendeteksi saat peluit wasit ditiup dalam video olahraga. Dan tentu saja, Anda dapat menggunakan teknik ini dalam berbagai beban kerja pengawasan, seperti mendengarkan suara tembakan atau suara tabrakan mobil dari mikrofon yang dipasang di atas jalan kota.

Posting ini menjelaskan cara mendeteksi suara dalam file audio meskipun ada suara latar belakang yang signifikan terjadi pada saat yang bersamaan. Terlebih lagi, mungkin mengejutkan, kami menggunakan teknik berbasis visi komputer untuk melakukan deteksi, menggunakan Rekognisi Amazon.

Menggunakan data audio dengan pembelajaran mesin

Langkah pertama dalam mendeteksi peristiwa audio adalah memahami bagaimana data audio direpresentasikan. Untuk keperluan posting ini, kami hanya berurusan dengan audio yang direkam, meskipun teknik ini bekerja dengan audio streaming.

Audio yang direkam biasanya disimpan sebagai urutan sampel suara, yang mengukur intensitas gelombang suara yang menghantam mikrofon selama perekaman, dari waktu ke waktu. Ada berbagai macam format untuk menyimpan sampel ini, tetapi pendekatan yang umum adalah menyimpan 10,000, 20,000, atau bahkan 40,000 sampel per detik, dengan setiap sampel berupa bilangan bulat dari 0–65535 (dua byte). Karena setiap sampel hanya mengukur intensitas gelombang suara pada saat tertentu, data suara umumnya tidak berguna untuk proses ML karena tidak memiliki fitur yang berguna dalam keadaan mentahnya.

Untuk membuat data itu berguna, sampel suara diubah menjadi gambar yang disebut a spektogram, yang merupakan representasi data audio yang menunjukkan intensitas pita frekuensi yang berbeda dari waktu ke waktu. Gambar berikut menunjukkan contohnya.

Sumbu X dari gambar ini mewakili waktu, artinya tepi kiri gambar adalah awal suara, dan tepi kanan gambar adalah akhir. Setiap kolom data dalam gambar mewakili pita frekuensi yang berbeda (ditunjukkan oleh skala di sisi kiri gambar), dan warna pada setiap titik mewakili intensitas frekuensi tersebut pada saat itu.

Skala vertikal untuk spektogram dapat diubah ke representasi lain. Misalnya, penskalaan linier berarti bahwa sumbu Y dibagi rata pada frekuensi, penskalaan logaritmik menggunakan skala log, dan seterusnya. Masalah dengan menggunakan representasi ini adalah bahwa frekuensi dalam file suara biasanya tidak terdistribusi secara merata, sehingga sebagian besar informasi yang mungkin kita minati akhirnya dikelompokkan di dekat bagian bawah gambar (frekuensi yang lebih rendah).

Untuk mengatasi masalah itu, contoh gambar kami adalah contoh dari a Spektogram Mel, yang diskalakan untuk mendekati bagaimana manusia mempersepsikan suara. Perhatikan indikator frekuensi di sepanjang sisi kiri gambar—mereka memberikan gambaran tentang bagaimana mereka didistribusikan secara vertikal, dan jelas bahwa itu adalah skala non-linear.

Selain itu, kami dapat memodifikasi pengukuran intensitas berdasarkan frekuensi berdasarkan waktu untuk meningkatkan berbagai fitur audio yang diukur. Seperti penskalaan sumbu Y yang diterapkan oleh spektogram Mel, yang lain menekankan fitur seperti intensitas 12 kelas nada khusus yang digunakan untuk mempelajari musik (kroma). Kelas lain menekankan fitur horizontal (harmonik) atau fitur vertikal (perkusi). Jenis suara yang dideteksi harus menentukan jenis spektogram yang digunakan untuk sistem deteksi.

Contoh spektogram sebelumnya mewakili klip musik yang berdurasi lebih dari 2 menit. Memperbesar mengungkapkan lebih detail, seperti yang ditunjukkan pada gambar berikut.

Angka-angka di sepanjang bagian atas gambar menunjukkan jumlah detik dari awal file audio. Anda dapat melihat dengan jelas urutan suara yang tampaknya berulang lebih dari empat kali per detik, yang ditunjukkan oleh warna-warna cerah di dekat bagian bawah gambar.

Seperti yang Anda lihat, ini adalah salah satu manfaat mengonversi audio ke spektogram—suara yang berbeda sering kali mudah terlihat dengan mata telanjang, dan bahkan jika tidak, suara tersebut sering kali dapat dideteksi menggunakan algoritma pendeteksi objek penglihatan komputer. Sebenarnya, inilah proses yang kami ikuti untuk mendeteksi suara.

Mencari suara diskrit dalam spektogram

Bergantung pada panjang file audio yang kami telusuri, menemukan suara diskrit yang berlangsung hanya satu atau dua detik adalah sebuah tantangan. Lihat spektogram pertama yang kami bagikan—karena kami melihat seluruh data berdurasi 3:30 menit, detail yang hanya berlangsung sekitar satu detik tidak akan terlihat. Kami memperbesar banyak untuk melihat ritme yang ditunjukkan pada gambar kedua. Jelas, dengan file suara yang lebih besar (dan karenanya spektogram yang jauh lebih besar), kami dengan cepat mengalami masalah kecuali kami menggunakan pendekatan yang berbeda. Pendekatan itu disebut jendela.

Windowing mengacu pada penggunaan jendela geser yang bergerak di seluruh spektogram, mengisolasi beberapa detik (atau kurang) pada suatu waktu. Dengan berulang kali mengisolasi bagian dari keseluruhan gambar, kami mendapatkan gambar yang lebih kecil yang dapat dicari keberadaan suara yang akan dideteksi. Karena setiap jendela dapat menghasilkan hanya sebagian dari gambar yang kita cari (seperti dalam kasus pencarian suara yang tidak dimulai tepat di awal jendela), pembuatan jendela sering dilakukan dengan jendela yang tumpang tindih. Misalnya, jendela pertama dimulai pada 0:00 dan diperpanjang 2 detik, kemudian jendela kedua dimulai pada 0:01 dan diperpanjang 2 detik, dan jendela ketiga dimulai pada 0:02 dan diperpanjang 2 detik, dan seterusnya.

Windowing membagi gambar spektogram secara horizontal. Kami dapat meningkatkan efektivitas proses deteksi dengan mengisolasi pita frekuensi tertentu dengan memotong atau mencari hanya bagian vertikal tertentu dari gambar. Misalnya, jika Anda tahu bahwa bel alarm yang ingin Anda deteksi menghasilkan suara yang berkisar dari satu frekuensi tertentu ke frekuensi lain, Anda dapat memodifikasi jendela saat ini untuk hanya mempertimbangkan rentang frekuensi tersebut. Itu sangat mengurangi jumlah data yang akan dimanipulasi, dan menghasilkan pencarian yang jauh lebih cepat. Ini juga meningkatkan akurasi, karena menghilangkan kemungkinan kecocokan positif palsu yang terjadi di pita frekuensi di luar rentang yang diinginkan. Gambar berikut membandingkan sumbu Y penuh (kiri) dengan sumbu Y terbatas (kanan).

Sumbu Y Penuh

Sumbu Y Terbatas

Sekarang setelah kita mengetahui cara mengulangi spektogram dengan pendekatan windowing dan memfilter ke pita frekuensi tertentu, langkah selanjutnya adalah melakukan pencarian suara yang sebenarnya. Untuk itu, kami menggunakan Label Kustom Amazon Rekognition. Fitur Label Kustom Rekognition dibangun dari kemampuan Amazon Rekognition yang ada, yang telah dilatih pada puluhan juta gambar di banyak kategori. Alih-alih ribuan gambar, Anda hanya perlu mengunggah satu set kecil gambar pelatihan (biasanya beberapa ratus gambar, tetapi ukuran set data pelatihan yang optimal harus diperoleh secara eksperimental berdasarkan kasus penggunaan khusus untuk menghindari pelatihan model yang kurang atau berlebihan. ) yang khusus untuk kasus penggunaan Anda melalui konsol Label Kustom Pengakuan.

Jika gambar Anda sudah diberi label, pelatihan Amazon Rekognition dapat diakses hanya dengan beberapa klik. Atau, Anda dapat melabeli gambar secara langsung di dalam antarmuka pelabelan Amazon Rekognition, atau menggunakan Kebenaran Dasar Amazon SageMaker untuk label mereka untuk Anda. Saat Amazon Rekognition memulai pelatihan dari kumpulan gambar Anda, itu menghasilkan model analisis gambar khusus untuk Anda hanya dalam beberapa jam. Di balik layar, Rekognition Custom Labels secara otomatis memuat dan memeriksa data pelatihan, memilih algoritme ML yang tepat, melatih model, dan menyediakan metrik performa model. Anda kemudian dapat menggunakan model khusus Anda melalui API Label Kustom Pengakuan dan mengintegrasikannya ke dalam aplikasi Anda.

Merakit data pelatihan dan melatih model Label Kustom Pengakuan

Dalam majalah Repo GitHub terkait dengan postingan ini, Anda akan menemukan kode yang menunjukkan cara mendengarkan suara alarm asap yang berbunyi, terlepas dari kebisingan latar belakang. Dalam hal ini, model Label Kustom Rekognition kami adalah model klasifikasi biner, yang berarti bahwa hasilnya adalah "suara alarm asap terdeteksi" atau "suara alarm asap tidak terdeteksi".

Untuk membuat model kustom, kita membutuhkan data pelatihan. Data pelatihan tersebut terdiri dari dua jenis utama: suara lingkungan, dan suara yang ingin Anda deteksi (seperti alarm asap yang berbunyi).

Data lingkungan harus mewakili berbagai macam lanskap suara yang khas untuk lingkungan tempat Anda ingin mendeteksi suara. Misalnya, jika Anda ingin mendeteksi suara alarm asap di lingkungan pabrik, mulailah dengan suara yang direkam di lingkungan pabrik tersebut di bawah berbagai situasi (tentu saja tanpa bunyi alarm asap).

Suara yang ingin Anda deteksi harus diisolasi jika memungkinkan, artinya rekaman harus berupa suara itu sendiri tanpa suara latar belakang lingkungan. Sebagai contoh kita, itu adalah suara alarm asap yang berbunyi.

Setelah Anda mengumpulkan suara-suara ini, kode di repo GitHub menunjukkan cara menggabungkan suara lingkungan dengan suara alarm asap dengan berbagai cara (dan kemudian mengubahnya menjadi spektogram) untuk membuat sejumlah gambar yang mewakili suara lingkungan. dengan dan tanpa suara alarm asap di atasnya. Gambar berikut adalah contoh beberapa suara lingkungan dengan suara alarm asap (bar horizontal terang) di atasnya.

Data pelatihan dan pengujian disimpan dalam Layanan Penyimpanan Sederhana Amazon (Amazon S3) ember. Struktur direktori berikut adalah titik awal yang baik untuk mengatur data di dalam bucket.

Kode sampel di repo GitHub memungkinkan Anda memilih berapa banyak gambar pelatihan yang akan dibuat. Label Kustom Pengakuan tidak memerlukan banyak gambar pelatihan. Satu set pelatihan yang terdiri dari 200–500 gambar sudah cukup.

Membuat proyek Label Kustom Pengakuan mengharuskan Anda menentukan URI folder S3 yang berisi data pelatihan, dan (opsional) data pengujian. Saat menentukan sumber data untuk pekerjaan pelatihan, salah satu opsinya adalah Pelabelan otomatis, seperti yang ditunjukkan pada tangkapan layar berikut.

Menggunakan opsi ini berarti Amazon Rekognition menggunakan nama folder sebagai nama label. Untuk kasus penggunaan deteksi alarm asap kami, struktur folder di dalam folder kereta dan tes terlihat seperti tangkapan layar berikut.

Gambar data pelatihan masuk ke folder tersebut, dengan spektogram yang berisi suara alarm asap masuk ke folder alarm, dan spektogram yang tidak berisi suara alarm asap di folder no_alarm map. Amazon Rekognition menggunakan nama tersebut sebagai nama kelas keluaran untuk model label khusus.

Pelatihan model label khusus biasanya membutuhkan waktu 30–90 menit. Di akhir pelatihan itu, Anda harus memulai model yang dilatih sehingga tersedia untuk digunakan.

Arsitektur ujung ke ujung untuk deteksi suara

Setelah kita membuat model, langkah selanjutnya adalah menyiapkan saluran inferensi, sehingga kita dapat menggunakan model untuk mendeteksi apakah ada suara alarm asap dalam file audio. Untuk melakukan ini, suara input harus diubah menjadi spektogram dan kemudian dijendela dan disaring berdasarkan frekuensi, seperti yang dilakukan untuk proses pelatihan. Setiap jendela spektogram diberikan kepada model, yang mengembalikan klasifikasi yang menunjukkan apakah alarm asap berbunyi atau tidak.

Diagram berikut menunjukkan contoh arsitektur yang mengimplementasikan pipa inferensi ini.

Arsitektur ini menunggu file audio ditempatkan ke dalam bucket S3, yang kemudian menyebabkan AWS Lambda fungsi yang akan dipanggil. Lambda adalah layanan komputasi berbasis peristiwa tanpa server yang memungkinkan Anda menjalankan kode untuk hampir semua jenis aplikasi atau layanan backend tanpa menyediakan atau mengelola server. Anda dapat memicu fungsi Lambda dari lebih dari 200 aplikasi layanan dan perangkat lunak AWS sebagai layanan (SaaS), dan hanya membayar untuk apa yang Anda gunakan.

Fungsi Lambda menerima nama ember dan nama kunci (atau nama file) file audio. File diunduh dari Amazon S3 ke memori fungsi, yang kemudian mengubahnya menjadi spektogram dan melakukan pemfilteran jendela dan frekuensi. Setiap bagian berjendela dari spektogram kemudian dikirim ke Amazon Rekognition, yang menggunakan model Amazon Custom Labels yang telah dilatih sebelumnya untuk mendeteksi suara. Jika suara itu ditemukan, fungsi Lambda akan memberi sinyal dengan menggunakan Layanan Pemberitahuan Sederhana Amazon (Amazon SNS) pemberitahuan. Amazon SNS menawarkan pendekatan pub/sub tempat pemberitahuan dapat dikirim ke Layanan Antrian Sederhana Amazon (Amazon SQS), fungsi Lambda, titik akhir HTTPS, alamat email, mobile push, dan banyak lagi.

Kesimpulan

Anda dapat menggunakan pembelajaran mesin dengan data audio untuk menentukan kapan suara tertentu muncul, bahkan saat suara lain muncul pada saat yang sama. Melakukannya memerlukan konversi suara menjadi gambar spektogram, dan kemudian memasukkan bagian yang berbeda dari spektogram itu dengan windowing dan penyaringan berdasarkan pita frekuensi. Label Kustom Pengakuan memudahkan untuk melatih model kustom untuk deteksi suara.

Anda dapat menggunakan GitHub repo berisi kode contoh untuk posting ini sebagai titik awal untuk eksperimen Anda sendiri. Untuk informasi lebih lanjut tentang deteksi peristiwa audio, lihat Deteksi Peristiwa Suara: Tutorial.

---

Tentang penulis

Greg Sommerville adalah Senior Prototyping Architect di tim AWS Prototyping dan Cloud Engineering, di mana dia membantu pelanggan AWS menerapkan solusi inovatif untuk masalah yang menantang dengan pembelajaran mesin, IoT, dan teknologi tanpa server. Dia tinggal di Ann Arbor, Michigan dan menikmati berlatih yoga, melayani anjingnya, dan bermain poker.

Jeff Harman adalah Senior Prototyping Architect di tim AWS Prototyping dan Cloud Engineering, di mana dia membantu pelanggan AWS menerapkan solusi inovatif untuk masalah yang menantang. Dia tinggal di Unionville, Connecticut dan menikmati pengerjaan kayu, pandai besi, dan Minecraft.