Farklı Bit Hızlarındaki MP3'leri Takılma ve Bozuk Atlama Olmadan Birleştirme

Adım adım

1. 1

   Düz yapıştırmanın neden ters gittiğini anlayın

   Bir MP3 dosyası küçük çerçevelerden (frame) oluşan bir akıştır ve her çerçevenin başlığı kendi bit hızını ve örnekleme hızını bildirir. Bu yüzden iki MP3 dosyasını bayt bayt uç uca ekleyebilirsiniz ve birçok oynatıcı yine de ses çıkarır — bu tuzağın bu kadar yaygın olmasının nedeni tam olarak budur. Ancak oynatıcılar tek ve tutarlı bir akış varsayar. 128 kbps'lik bir dosyayla 320 kbps'lik bir dosyanın, daha da kötüsü 44,1 kHz'lik bir dosyayla 48 kHz'lik bir dosyanın birleşim noktasında kod çözücüler çıtırtı, kısa bir bozuk ses patlaması ya da ani bir perde ve hız kayması üretebilir; çünkü kod çözücüye aniden ayarlanmadığı çerçeveler verilmektedir. Bazı oynatıcılar bunu tolere eder, bazıları etmez; aynı dosya araç teybinde, telefonda ve masaüstü uygulamada farklı davranabilir.

2. 2

   Sürenin ve ilerleme çubuğunun neden yalan söylediğini bilin

   Değişken bit hızlı (VBR) MP3'ler dosyanın başında özel bir başlık çerçevesi taşır — yaygın olarak Xing veya VBRI başlığı — ve bu başlık oynatıcılara toplam çerçeve sayısını ve tüm dosya için bir atlama tablosunu bildirir. Dosyaları uç uca eklediğinizde bu başlık hâlâ yalnızca ilk dosyayı tarif eder. Sonuç: birleştirilmiş dosya birinci parçanın süresini bildirir, ilerleme çubuğu gerçek sesin yalnızca bir kısmını kapsar ve '%50'ye atlamak alakasız bir yere düşer. Sabit bit hızlı dosyalarda bile süreyi dosya boyutunu ilk çerçevelerin bit hızına bölerek tahmin eden oynatıcılar, ikinci yarısı farklı bit hızı kullanan bir dosyayı yanlış raporlar. Bu hatalar kozmetik gibi görünür ama atlamanın asıl amaç olduğu sesli kitapları ve uzun kayıtları kullanılmaz hale getirir.

3. 3

   Çözümü benimseyin: tek ortak formata yeniden kodlayın

   Sağlam çözüm şudur: her girdiyi ham sese çöz, hepsini tek örnekleme hızına yeniden örnekle ve tek bit hızında yepyeni tek bir MP3 kodla. Bu, tek bir doğru başlığa sahip, gerçekten tekdüze bir akış üretir: süreler doğrudur, atlama her yerde çalışır ve dosyanın ortasında kod çözücünün takılacağı format değişikliği yoktur. Bedeli nesil kaybıdır (generation loss) — kayıplı sesi çözüp yeniden kodlamak bir miktar daha ayrıntıyı atar. Konuşma, ders ve podcast'lerde makul bir bit hızındaki kayıp pratikte duyulmaz. Adil bir takastır: her oynatıcıda doğru davranan bir dosya karşılığında küçük, tek seferlik bir kalite bedeli.

4. 4

   Hedef bit hızını ve örnekleme hızını seçin

   İki makul strateji var. En iyi kaynağa eşitleyin: en yüksek kaliteli girdiniz 44,1 kHz'de 192 kbps ise birleştirilmiş dosyayı 192 kbps / 44,1 kHz kodlayın — en iyi kaynağınızın üstüne çıkmak, olmayan kaliteyi ekleyemez, yalnızca yer israf eder. Ya da standartlaştırın: genel amaçlı sağlam bir hedef olarak 192 kbps'i, dosya boyutu önemli değilse ve yeniden kodlamanın kalite bedelini olabildiğince küçültmek istiyorsanız 320 kbps'i seçin. O kaynağın kalitesi sizin için önemliyse asla en iyi kaynağınızın altını hedeflemeyin. Örnekleme hızında 44,1 kHz en güvenli ortak paydadır; kaynaklarınızın çoğu zaten 48 kHz ise 48 kHz'i seçin.

5. 5

   Dosyaları sırayla birleştirin

   MP3 Birleştirici aracını açın, dosyalarınızı ekleyin ve birleştirmeden önce çalma sırasına dizin — sonradan sıra değiştirmek işi baştan yapmak demektir. Dosya adına dayalı sıralama tuzaklarına dikkat edin: 'bolum10' alfabetik olarak 'bolum2'den önce gelir; bu yüzden sıralamaya güvenmek yerine diziyi gözle kontrol edin. Ardından birleştirip tek çıktı dosyasını indirin.

6. 6

   Sonucu şüpheci gibi doğrulayın

   Üç kontrol iki dakika sürer. Birincisi: bildirilen süre parçaların toplamına eşit mi? Yalnızca ilk dosyanın uzunluğunu gösteriyorsa çıktı düzgün yeniden oluşturulmamış demektir. İkincisi: birkaç noktaya — özellikle her birleşim yerinin hemen öncesine ve sonrasına — atlayın ve konum çubuğuyla sesin uyuştuğunu doğrulayın. Üçüncüsü: her birleşim yerini çıtırtı veya seviye sıçraması için dinleyin. Seviye sıçraması bir birleştirme hatası değildir; kaynak dosyaların yükseklikleri farklıydı demektir — bu bir normalizasyon sorunudur, yapıştırma sorunu değil.