M4A को AAC में बदलें

यही वह फ़र्क़ है जिसके लिए यह जोड़ी बनी है, और यही वह है जिसे ज़्यादातर कन्वर्टर पेज ग़लत बता देते हैं। AAC एक कोडेक है — 1997 में ISO/IEC 13818-7 के तौर पर मानकीकृत, MP3 का बनाया गया उत्तराधिकारी, और असल में आवाज़ को कंप्रेस करने वाली चीज़। M4A एक कंटेनर है: एक MP4 फ़ाइल, जिसे Apple 2003 से iTunes 4 के साथ इस्तेमाल कर रहा है, जिसमें एक ऑडियो ट्रैक होता है जो आम तौर पर AAC ही होता है। डिस्क पर लगभग हर `.m4a` और लगभग हर `.aac` एक ही कोडेक रखते हैं, और दोनों फ़ाइलों का फ़र्क़ उसके चारों ओर लिपटी चीज़ में है।

MP4 हेडर सजावट नहीं है। यह रिकॉर्ड करता है ऑडियो कितना लंबा है, कितने चैनल हैं, हर सैंपल कहाँ से शुरू होता है ताकि प्लेयर किसी भी सेकंड पर सीक कर सके, और टाइटल, कलाकार व कवर तस्वीर के लिए मेटाडेटा ब्लॉक। सादी `.aac` फ़ाइल में आम तौर पर इनमें से कुछ नहीं होता।

सादी `.aac` फ़ाइल एक ADTS स्ट्रीम है, यानी फ़्रेम की लगातार धारा, हर एक सात-बाइट के हेडर से शुरू होकर सिर्फ़ उस फ़्रेम की बात करता है, आगे कुछ नहीं। डिज़ाइन का लक्ष्य प्रसारण था, जहाँ रिसीवर किसी भी पल जुड़ सकता है और उसे बिना शुरुआत देखे फ़्रेम की सीमा ढूँढकर डिकोड करना शुरू कर पाना चाहिए।

इससे ADTS को दो असली गुण मिलते हैं। फ़ाइल का कोई भी बाइट रेंज जो फ़्रेम सीमा से शुरू हो वह ख़ुद एक वैध फ़ाइल है, यही वजह है HLS ऑडियो को `.aac` टुकड़ों की श्रृंखला के तौर पर भेज सकता है। और दो ADTS फ़ाइलें बिना हेडर बदले सिर्फ़ जोड़कर मिलाई जा सकती हैं। यही गुण स्ट्रीमिंग और embedded सिस्टम इसे चाहते हैं, फ़ाइल-स्तरीय हेडर देने वाली हर चीज़ छोड़ने की क़ीमत पर।

इस जोड़ी की साफ़-सुथरी कहानी यह है कि दोनों फ़ाइलों में AAC है, तो बदलाव बस दोबारा-लपेटना है — MP4 से फ़्रेम निकालो, हर एक पर ADTS हेडर लपेटो, लिख दो, कुछ मत खोओ। यह असली तकनीक है और इस्तेमाल होने वाली लाइब्रेरी इसे संभालती है।

यह कन्वर्टर इसे इस्तेमाल नहीं करता। हर कंप्रेस्ड लक्ष्य के लिए एनकोडर को एक bitrate दिया जाता है, जो लाइब्रेरी के stream-copy शॉर्टकट को बंद कर देता है, तो ऑडियो सैंपल तक डिकोड होकर फिर एनकोड होता है। व्यावहारिक नतीजा है पहले से लॉसी ऑडियो पर दूसरा लॉसी पास — असली, ठीक सेटिंग पर आम तौर पर सुनाई न देने वाला, कुछ नहीं नहीं। अगर नतीजा मायने रखता है तो High quality चुनिए, जो तीन बैंड में AAC की सबसे ऊँची, 192 kbps लिखता है।

फ़र्मवेयर और embedded डिकोडर मुख्य मामला हैं। फ़्रेम-स्तर के AAC डिकोडर वाली चिप जिसमें MP4 पार्सर नहीं, उसे ठीक यही चाहिए: फ़्रेम थमाओ और वह उन्हें चला देगी। DSP evaluation बोर्ड, कार और औद्योगिक ऑडियो मॉड्यूल, और बहुत-सा सेट-टॉप व IP-कैमरा फ़र्मवेयर इसी तरह बना है।

बाक़ी हैं ingest और पुराने API। कुछ स्ट्रीमिंग ingest रास्ते elementary स्ट्रीम लेते हैं और अपनी पैकेजिंग ख़ुद करते हैं। पुराने Android और Java ऑडियो इंटरफ़ेस ADTS सीधे पढ़ते हैं। अगर आप इनमें से किसी हालत में नहीं, तो जो M4A आपके पास पहले से है वह बेहतर फ़ाइल है और यह बदलाव आपकी ज़िंदगी मुश्किल करेगा।

तीन चीज़ें, और हर एक तुरंत दिखती है। Duration ग़ायब हो जाता है, क्योंकि ADTS में उसके लिए फ़ील्ड नहीं — प्लेयर फ़ाइल आकार और पहले फ़्रेम के bitrate से अंदाज़ा लगाता है और bitrate बदलते ही ग़लत होता है। Sample table ग़ायब हो जाती है, तो सीक करने का मतलब है byte offset का अंदाज़ा लगाना और अगला sync word खोजना।

और मेटाडेटा ब्लॉक ग़ायब हो जाता है, कवर आर्ट की तय जगह के साथ। इसकी जगह लेता है आगे जोड़ा गया ID3v2 हेडर — वही तरीक़ा जो MP3 इस्तेमाल करता है — जो AAC स्पेसिफ़िकेशन का हिस्सा नहीं, एक रिवाज़ है। Desktop प्लेयर आम तौर पर इसे पढ़ लेते हैं। Embedded डिकोडर अक्सर नहीं, और कुछ ID3 बाइट को ख़राब ऑडियो समझ लेते हैं।

Quality नियंत्रण असली bitrate तय करता है और AAC के लिए तय सेट है: Small file 96 kbps, Balanced 128 kbps और High quality 192 kbps लिखता है। 256 या 320 का विकल्प नहीं, जो एनकोडर के रास्ते की सीमा है, कोडेक की नहीं।

इस जोड़ी के लिए चुनाव आसान है: लगभग हमेशा High quality। आप पहले से एक बार कंप्रेस हो चुके ऑडियो को दोबारा एनकोड कर रहे हैं, और दूसरे पास को सुनाई देने से बचाने का इकलौता बचाव यह है कि एनकोडर को इतनी जगह दी जाए कि वह अपनी तरफ़ से लगभग कुछ न जोड़े।

रजिस्ट्री M4A के लिए AAC और ALAC दोनों को कोडेक गिनती है, और iTunes में CD से रिप की गई फ़ाइल शायद Apple Lossless रखती हो। ADTS ALAC बिल्कुल नहीं ढो सकता — यह एक AAC फ़्रेम फ़ॉर्मेट है — तो इस बदलाव का कोई भी संस्करण लॉसलेस स्रोत को नहीं बचा सकता।

व्यवहार में जो होता है वह है फ़ाइल चुपचाप ट्रांसकोड होने की बजाय रुक जाती है: ALAC इस डिकोडिंग रास्ते पर उपलब्ध कोडेक में नहीं, तो बदलाव कहता है फ़ाइल में कुछ नहीं बदला जा सका। आकार पहले से बता देता है आपके पास कौन-सी M4A है: AAC के चार मिनट तीन से पाँच मेगाबाइट, Apple Lossless के बीस से तीस।

ADTS हेडर हर फ़्रेम में चैनल कॉन्फ़िगरेशन और सैंपलिंग फ़्रीक्वेंसी इंडेक्स रखते हैं, तो मोनो मोनो रहता है, स्टीरियो स्टीरियो, और स्रोत की सैंपल रेट बिना बदले लिखी जाती है — असामान्य वाली भी जो कोई embedded लक्ष्य ख़ास तौर पर माँग सकता है।

फ़्रीक्वेंसी इंडेक्स मनमानी संख्या नहीं, तय टेबल है, जो किसी डिवाइस के रेट तय करने पर जानने लायक़ सीमा है। मानक मान ढँके हैं; टेबल से बाहर की असामान्य रेट के लिए ADTS में कोई जगह नहीं। जहाँ स्रोत कॉन्फ़िगरेशन बिल्कुल एनकोड नहीं हो सकता, बदलाव फ़ेल होने की बजाय दो चैनल 48,000 Hz पर वापस जाता है।

इस जोड़ी में एक ट्रायल रन सबसे भरोसे से अपनी क़ीमत चुका देता है, क्योंकि गंतव्य आम तौर पर कोई इंसान नहीं, कोई डिवाइस है। एक फ़ाइल बदलिए, लक्ष्य पर रखिए, और तीन चीज़ पुष्ट कीजिए: क्या यह चलती है, क्या यह पहले फ़्रेम से चलती है छोड़े बिना, और क्या सामने का ID3 हेडर डिकोडर को परेशान नहीं करता।

यह ठीक होने पर, बैच सीधा है — फ़ोल्डर छोड़िए, ZIP लीजिए, प्रति फ़ाइल 100 MB सीमा के साथ, सौ फ़ाइल प्रति बैच, और कहीं कोई अपलोड नहीं। डिकोडिंग आपके अपने डिवाइस के कोडेक इस्तेमाल करती है और AAC एनकोडर टैब में चलता है।