8, 16 ve 48 kHz: μ-law’dan PCM’e güvenilir STT hattı

Kısa cevap: STT servisi μ-law’ı doğrudan kabul ediyorsa kaynak biçimini koruyabilirsiniz. PCM gerekiyorsa doğrusal PCM’e çözün; hedef ayrıca farklı hız istiyorsa yeniden örnekleyin. Ardından giriş sözleşmesini gönderilen gerçek baytlara göre güncelleyin. Dosya uzantısını veya hız etiketini değiştirmek ses dönüşümü yapmaz. Güvenilir bir hat, her sınırdan hangi biçimin geçtiğini açıklayabilir. Bu kararı sesin geldiği kanalın adına göre değil, kaynak ile hedefin belgelenmiş biçimlerine göre verin.

8, 16 ve 48 kHz neyi söyler?

Örnekleme hızı, kanal başına saniyedeki örnek sayısıdır. [1] Ancak bir sayı, sesin kodlamasını veya kanal düzenini açıklamaz. Mühendislik sözleşmesinde bu alanları ayrı tutun. “Telefon sesi” gibi insanın anlayabildiği bir açıklama, ham ses baytlarını yorumlamak için yeterli değildir. Veri üreticisi değiştiğinde açıklamanın hâlâ aynı bayt düzenini ifade ettiğini yeniden kontrol edin.

Kapsayıcı ile codec’i karıştırmayın

WAV bir dosya kapsayıcısıdır; içindeki sesin mutlaka doğrusal PCM olması gerekmez. [1] Benzer biçimde bir taşıma zarfının bulunması, içerideki sesin decoder gerektirmediğini göstermez. Dosya adı veya HTTP içerik türü üzerinden tahmin yürütmek yerine başlıkları ve üreticinin biçim bilgisini inceleyin. Ham akışta başlık bulunmuyorsa gerekli tanım dışarıdan gelmelidir. Bu tanımı sesle birlikte taşıyan bir kayıt, sonradan yapılacak hata incelemesini kolaylaştırır.

Önce μ-law çözme, sonra gerekiyorsa yeniden örnekleme

μ-law baytları doğrusal genlik değerleri değildir; decoder onları doğrusal örneklere dönüştürür. [3] Bu kavramsal ayrımı bir üretim kütüphanesi seçimiyle karıştırmayın. Ses bağdaştırıcısında decoder’ın giriş ve çıkışını açıkça belirtin. Önerdiğimiz sıra, taşıma zarfını açmak, kodlamayı çözmek, gerekirse yeniden örneklemek ve hedef biçimde paketlemektir. Böylece kodlanmış baytları yanlışlıkla PCM örnekleri gibi işleyen bir adım kolayca fark edilir.

FFmpeg’in resampler arayüzü giriş ve çıkış örnekleme hızlarını, örnek biçimlerini ve kanal düzenlerini ayrı tanımlar. [6] Aynı ayrımı kendi arayüzünüzde de kullanın. Dönüşümün yalnız ayar dosyasında yazılması yeterli değildir; çıktı gerçekten bu ayarlara göre üretilmelidir. Her aşamanın neyi değiştirdiğini isimlendirmek, bir sorun olduğunda bütün hattı yeniden kurma ihtiyacını azaltır.

STT giriş sözleşmesini yazın

Sözleşmede kodlama, gerçek örnekleme hızı, kanal sayısı, örnek gösterimi, bayt sırası ve kapsayıcı bulunmalıdır. Sesin hangi konuşmacıya veya çağrı ayağına ait olduğunu da uygulama bağlamına ekleyin. Google Cloud’un ham LINEAR16 açıklaması, işaretli 16 bit little-endian örnekler ister. [5] Bu bir sağlayıcı örneğidir; bütün STT servislerine otomatik olarak genellenmez. Entegrasyonunuzda kullanılan API sürümünün ve modelin istediği biçimi ayrıca doğrulayın.

Kaynak hızını korumak kabul edilen bir seçenekse gereksiz dönüşüm eklemeyin. Google’ın telefon sesi için önerisi, doğal örnekleme hızını göndermektir. [4] Hedef gerçekten başka hız istiyorsa dönüştürme gerekçesini sözleşmeye yazın. Daha önce çıkarılmış frekans bilgisi yeniden örnekleme ile geri gelmez; bu, doğal kaynağı koruma önerisinin mühendislik açısından önemli sonucudur. Yeni bir hız, yeni bir mikrofon kaydı anlamına gelmez.

Uygulama örneği: telefon sesini STT’ye bağlama

Twilio Media Streams, başlangıç mesajında μ-law, 8000 Hz ve tek kanal bildirir; ses yükü base64 ile taşınır. [2] Varsayımsal bağdaştırıcımız başlangıç bilgisini doğrular ve yükü base64’ten baytlara açar. Bundan sonra hedef sözleşmesine göre dallanır: STT servisi μ-law kabul ediyorsa kodlanmış baytları doğrudan gönderir. PCM gerekiyorsa μ-law decoder ile çözülen örnekleri kullanır. Farklı örnekleme hızı da gerekiyorsa PCM üzerinde yeniden örnekleme yapar ve ardından hedef biçimde paketler.

Her çıkışta sözleşmenin o çıkışı tarif ettiğini kontrol ederiz. Örneğin μ-law girişini PCM’e çözdükten sonra eski “MULAW” alanını korumak, hedefe farklı veri tarif etmek olur. Hedef biçime geçiş uygulama içinde tek, görünür bir sınırda gerçekleşsin.

Hataları ses ve metadata birlikteyken inceleyin

Boş veya anlamsız transkripsiyon gördüğünüzde önce aynı veriyi doğru biçim tanımıyla dinleyin. Kaynak okunabilirken hedef okunamıyorsa dönüşüm sınırını inceleyin. Süre değişmişse etiket, örnek sayısı ve zaman çizelgesini karşılaştırın. Konuşmacılar beklenmedik biçimde birleşmişse kanal kararı yeniden ele alınmalıdır. Uygulama günlüğünde kişisel konuşma içeriği yerine biçim alanlarını ve dönüşüm adlarını göstermek, teknik sorunu daha dar bir veriyle araştırmanıza yardımcı olabilir.

Kontrol listesi

• Kaynağın bildirdiği kodlama, kanal sayısı ve örnekleme hızını doğrulayın.
• Base64 açma ile ses çözme işlemlerini farklı aşamalara ayırın.
• Yeniden örnekleme gerekçesini ve hedef çıktı biçimini belgeleyin.
• Decoder sonrasındaki PCM sözleşmesini gönderilen gerçek baytlarla eşleştirin.
• Akış parçaları arasında dönüştürücü durumunun nasıl korunduğunu inceleyin.
• Kısa bir konuşma örneğini girişte ve çıkışta dinleyerek süreyi karşılaştırın.

Sık sorulan sorular

8000 değerini 16000 olarak değiştirirsem dönüşüm olur mu? Hayır. Bu yalnız verinin yorumlanma talimatını değiştirir. Hedefe gönderilen örnekler de gerçekten dönüştürülmeli, ardından yeni hız bildirilmeli. Aksi halde metadata ile ses farklı şeyler anlatır.

PCM’e çözmek kaybedilen ayrıntıyı geri getirir mi? Decoder, elindeki kodlanmış sesi doğrusal bir gösterime taşır. Daha önce kaybolan bilgi için yeni bir kaynak yaratmaz. Çözme, yeniden örnekleme ve tanıma modelini ayrı kararlar olarak değerlendirin.

Bütün sesleri tek biçime çevirmek mantıklı mı? Ortak bir iç biçim bakım kolaylığı sağlayabilir; ancak bunu seçilmiş bir mimari kural olarak belgeleyin. Kaynak ve hedef zaten anlaşabiliyorsa yeni dönüşümün neden gerekli olduğunu açıklayabilmelisiniz.