מבוא לקידוד אודיו ב-Cloud Speech-to-Text

קידוד אודיו מתייחס לאופן שבו נתוני אודיו מאוחסנים ומועברים. בדף הזה מוסבר איך קידודים כאלה פועלים ביחס ל-Cloud Speech-to-Text API.

הנחיות לבחירת הקידוד הטוב ביותר לאפליקציה שלכם מפורטות במדריך לשיטות מומלצות.

הערה: המידע שמופיע כאן הוא סקירה כללית. קידוד של אודיו דיגיטלי הוא נושא מורכב, ולא צריך להכיר את הפרטים כדי להשתמש ב-Cloud Speech-to-Text API. חלק מהמידע הזה יכול לעזור לכם להבין איך ה-API פועל ואיך צריך ליצור ולעבד אודיו באפליקציות שלכם.

פורמטים לעומת קידודים של אודיו

פורמט אודיו לא שווה לקידוד אודיו. לדוגמה, קובצי אודיו בפורמט WAV מגדירים את הפורמט של הכותרת של קובץ אודיו, אבל הם לא קידוד אודיו בעצמם. בקבצי WAV נעשה לעיתים קרובות (אבל לא תמיד) שימוש בקידוד PCM ליניארי. אל תניחו שלקובץ WAV יש קידוד מסוים עד שתבדקו את הכותרת שלו.

עם זאת, FLAC הוא גם פורמט קובץ וגם קידוד, ולפעמים זה גורם לבלבול. כדי לשלוח קובץ FLAC ל-Cloud Speech-to-Text API, הוא צריך להכיל את קצב הדגימה בכותרת. ‫FLAC הוא הקידוד היחיד שבו נתוני האודיו צריכים לכלול כותרת. בכל קידודי האודיו האחרים, נתוני האודיו לא כוללים כותרת. כשמתייחסים ל-FLAC ב-Cloud Speech-to-Text API, תמיד מתכוונים לקודק. כשמתייחסים לפורמט קובץ FLAC, משתמשים בפורמט 'קובץ FLAC'.

הערה: אין חובה לציין את הקידוד ואת קצב הדגימה של קובצי WAV או FLAC. אם לא מציינים את הקידוד, Cloud Speech-to-Text קובע באופן אוטומטי את הקידוד ואת קצב הדגימה של קובצי WAV או FLAC על סמך כותרת הקובץ. אם מציינים ערך קידוד או קצב דגימה שלא תואם לערך בכותרת הקובץ, Cloud Speech-to-Text מחזיר שגיאה.

קידודי האודיו הנתמכים ב-Cloud Speech-to-Text

‫Cloud Speech-to-Text API תומך במספר קידודים שונים. בטבלה הבאה מפורטים רכיבי codec של אודיו שנתמכים:

קודק	שם	ללא אובדן מידע	הערות שימוש
MP3	MPEG Audio Layer III	לא	קידוד MP3 הוא תכונת בטא שזמינה רק בגרסה v1p1beta1. פרטים נוספים מופיעים במאמרי העזרה של RecognitionConfig.
FLAC	Free Lossless Audio Codec	כן	נדרש 16 ביט או 24 ביט לסטרימינג
LINEAR16	Linear PCM	כן	קידוד של 16 ביט עם אפנון קוד-דופק ליניארי (PCM). הכותרת חייבת להכיל את קצב הדגימה.
MULAW	‫μ-law	לא	קידוד PCM‏ 8-ביט
AMR	Adaptive Multi-Rate Narrowband	לא	תדירות הדגימה חייבת להיות 8,000 הרץ
AMR_WB	Adaptive Multi-Rate Wideband	לא	תדירות הדגימה חייבת להיות 16,000 הרץ
OGG_OPUS	פריימים של אודיו מקודד בשיטת Opus במאגר מסוג Ogg	לא	תדירות הדגימה חייבת להיות אחת מהאפשרויות הבאות: ‎8000 Hz, 12000 Hz, 16000 Hz, 24000 Hz, or 48000 Hz
SPEEX_WITH_HEADER_BYTE	Speex wideband	לא	תדירות הדגימה חייבת להיות 16,000 הרץ
WEBM_OPUS	WebM Opus	לא	תדירות הדגימה חייבת להיות אחת מהאפשרויות הבאות: ‎8000 Hz, 12000 Hz, 16000 Hz, 24000 Hz, or 48000 Hz

הערה: FLAC הוא גם קודק אודיו וגם פורמט קובץ אודיו. כדי לתמלל קובצי אודיו באמצעות קידוד FLAC, צריך לספק אותם בפורמט קובץ FLAC, שכולל כותרת שמכילה מטא-נתונים.

שירות Cloud Speech-to-Text תומך בקובצי WAV עם אודיו מקודד בפורמט LINEAR16 או MULAW.

מידע נוסף על רכיבי codec של אודיו ב-Cloud Speech-to-Text זמין במאמרי העזרה של AudioEncoding.

אם יש לכם אפשרות בחירה כשאתם מקודדים את חומר המקור, השתמשו בקידוד ללא אובדן נתונים כמו FLAC או LINEAR16 כדי לשפר את זיהוי הדיבור. הנחיות לבחירת קודק מתאים למשימה מפורטות במאמר שיטות מומלצות.

למה כדאי לקודד?

האודיו מורכב מצורות גל, שכוללות שילוב של גלים בתדרים ובאמפליטודות שונים. כדי לייצג את צורות הגל האלה במדיה דיגיטלית, צריך לדגום את צורות הגל בקצב שמאפשר (לפחות) לייצג צלילים בתדר הגבוה ביותר שרוצים לשכפל, וגם לאחסן מספיק עומק סיביות כדי לייצג את האמפליטודה המתאימה (עוצמת הקול) של צורות הגל בדגימת הצליל.

היכולת של מכשיר לעיבוד אודיו ליצור מחדש תדרים נקראת תגובת תדרים, והיכולת שלו ליצור עוצמת קול מתאימה נקראת טווח דינמי. המונחים האלה ביחד מתייחסים לרוב לנאמנות של מכשיר אודיו. קידוד, בצורתו הפשוטה ביותר, הוא אמצעי לשחזור צליל באמצעות שני העקרונות הבסיסיים האלה, וגם לאחסון ולהעברה של נתונים כאלה בצורה יעילה.

תדירויות דגימה

הסאונד קיים כגל אנלוגי. פלח של אודיו דיגיטלי מתקרב לגל האנלוגי הזה על ידי דגימת האמפליטודה של הגל האנלוגי בקצב מהיר מספיק כדי לחקות את התדרים הפנימיים של הגל. קצב הדגימה של קטע אודיו דיגיטלי מציין את מספר הדגימות שצריך לקחת מחומר המקור של האודיו (לשנייה). קצב דגימה גבוה מגדיל את היכולת של אודיו דיגיטלי לייצג נאמנה תדרים גבוהים.

כתוצאה ממשפט נייקוויסט-שאנון, בדרך כלל צריך לדגום יותר מפי שניים מהתדר הגבוה ביותר של כל גל קול שרוצים לתעד באופן דיגיטלי. כדי לייצג אודיו בטווח השמיעה של בני אדם (20-20000 הרץ), למשל, פורמט אודיו דיגיטלי צריך לדגום לפחות 40000 פעמים בשנייה (וזו אחת הסיבות לכך שאודיו בתקליטור משתמש בקצב דגימה של 44100 הרץ).

עומקי ביט

עומק הביט משפיע על הטווח הדינמי של דגימת אודיו נתונה. עומק ביטים גבוה יותר מאפשר לייצג אמפליטודות מדויקות יותר. אם יש הרבה צלילים חזקים וחלשים באותה דגימת אודיו, תצטרכו עומק ביטים גדול יותר כדי לייצג את הצלילים האלה בצורה נכונה.

בנוסף, עומקי ביט גבוהים יותר מפחיתים את יחס האות לרעש בדגימות אודיו. האודיו המוזיקלי של תקליטור מסופק באמצעות עומק סיביות של 16 ביט. ב-DVD Audio נעשה שימוש ב-24 ביטים של עומק ביטים, בעוד שרוב ציוד הטלפוניה משתמש ב-8 ביטים של עומק ביטים. (טכניקות דחיסה מסוימות יכולות לפצות על עומקי ביט קטנים יותר, אבל בדרך כלל הן גורמות לאובדן נתונים).

אודיו לא דחוס

ברוב המקרים, עיבוד אודיו דיגיטלי מתבסס על שתי הטכניקות האלה (קצב דגימה ועומק סיביות) כדי לאחסן נתוני אודיו בצורה פשוטה. אחת מהטכניקות הפופולריות ביותר של אודיו דיגיטלי (שנמצאת בשימוש נפוץ בתקליטורים) נקראת Pulse Code Modulation (PCM). האודיו נדגם במרווחי זמן מוגדרים, והאמפליטודה של הגל שנדגם בנקודה הזו מאוחסנת כערך דיגיטלי באמצעות עומק הביטים של הדגימה.

‫Linear PCM (שמציין שתגובת האמפליטודה אחידה באופן ליניארי בדגימה) הוא התקן שמשמש בתקליטורים, ובקידוד LINEAR16 של Cloud Speech-to-Text API. שני הקידודים יוצרים זרם לא דחוס של בייטים שתואמים ישירות לנתוני האודיו, ושני התקנים מכילים עומק של 16 ביט. ב-Linear PCM נעשה שימוש בתדירות דגימה של 44,100 הרץ בתקליטורים, שמתאימה להרכבה מחדש של מוזיקה. עם זאת, תדירות דגימה של 16,000 הרץ מתאימה יותר להרכבה מחדש של דיבור.

‫Linear PCM (LINEAR16) היא דוגמה לאודיו לא דחוס, כי הנתונים הדיגיטליים מאוחסנים בדיוק כמו שמשתמע מהתקנים הקודמים. אם קוראים סטרימינג של בייטים עם ערוץ אחד שמקודד באמצעות Linear PCM, אפשר לספור כל 16 ביטים (2 בייטים), למשל, כדי לקבל ערך משרעת נוסף של צורת הגל. כמעט כל המכשירים יכולים לערוך נתונים דיגיטליים כאלה באופן מקורי – אפשר אפילו לחתוך קובצי אודיו של Linear PCM באמצעות עורך טקסט – אבל אודיו לא דחוס הוא לא הדרך הכי יעילה להעברה או לאחסון של אודיו דיגיטלי. לכן, ברוב המקרים, האודיו עובר דחיסה דיגיטלית.

אודיו דחוס

כמו כל הנתונים, נתוני אודיו עוברים לעיתים קרובות דחיסה כדי שיהיה קל יותר לאחסן אותם ולהעביר אותם. הדחיסה בקידוד האודיו יכולה להיות ללא אובדן מידע או דחיסת נתונים (lossy). אפשר לפתוח דחיסה ללא אובדן נתונים כדי לשחזר את הנתונים הדיגיטליים לצורה המקורית שלהם. דחיסה עם אובדן נתונים בהכרח מסירה חלק מהמידע הזה במהלך הדחיסה והפירוק, והיא מוגדרת באמצעות פרמטרים שמציינים כמה סובלנות לתת לטכניקת הדחיסה להסרת נתונים.

דחיסה ללא אובדן נתונים

דחיסה ללא אובדן מידע דוחסת נתוני אודיו דיגיטליים באמצעות סידור מחדש מורכב של הנתונים המאוחסנים, אבל לא גורמת לירידה באיכות של הדגימה הדיגיטלית המקורית. כשמבצעים דחיסה ללא אובדן נתונים, לא יאבד מידע כשמפזרים את הנתונים לצורה הדיגיטלית המקורית שלהם.

אז למה לפעמים יש פרמטרים לאופטימיזציה בשיטות דחיסת נתונים ללא אובדן מידע? הפרמטרים האלה לרוב מקטינים את גודל הקובץ על חשבון זמן הפתיחה. לדוגמה, ב-FLAC נעשה שימוש בפרמטר של רמת דחיסה מ-0 (המהירה ביותר) עד 8 (גודל הקובץ הקטן ביותר). דחיסת FLAC ברמה גבוהה יותר לא תגרום לאובדן מידע בהשוואה לדחיסה ברמה נמוכה יותר. במקום זאת, אלגוריתם הדחיסה יצטרך להשקיע יותר אנרגיה חישובית כשיוצר או מפרק אודיו דיגיטלי מקורי.

‫Cloud Speech-to-Text API תומך בשני קידודים ללא אובדן נתונים: FLAC ו-LINEAR16. מבחינה טכנית, LINEAR16 הוא לא 'דחיסת נתונים ללא אובדן מידע' כי אין דחיסת נתונים מלכתחילה. אם גודל הקובץ או העברת הנתונים חשובים לכם, כדאי להשתמש ב-FLAC.

דחיסת נתונים עם אובדן נתונים

לעומת זאת, דחיסה עם אובדן נתונים דוחסת נתוני אודיו על ידי ביטול או צמצום של סוגים מסוימים של מידע במהלך בניית הנתונים הדחוסים. ‫Cloud Speech-to-Text API תומך בכמה פורמטים עם אובדן נתונים, אבל מומלץ להימנע מהם אם יש לכם שליטה על האודיו, כי אובדן נתונים עלול להשפיע על דיוק הזיהוי.

קודק MP3 הפופולרי הוא דוגמה לטכניקת קידוד עם אובדן נתונים. כל טכניקות הדחיסה של MP3 מסירות אודיו מחוץ לטווח האודיו הרגיל של בני אדם, ומשנות את כמות הדחיסה על ידי שינוי קצב הדגימה האפקטיבי של קודק ה-MP3, או כמות הסיביות לשנייה לאחסון נתוני האודיו.

לדוגמה, ל-CD סטריאו שמשתמש ב-PCM לינארי של 16 ביט יש קצב העברת נתונים אפקטיבי של:

44100 * 2 channels * 16 bits = 1411200 bits per second (bps) = 1411 kbps

דחיסת MP3 מסירה נתונים דיגיטליים כאלה באמצעות קצב העברת נתונים כמו 320kbps,‏ 128kbps או 96kbps, למשל, וכתוצאה מכך יש ירידה באיכות האודיו. בנוסף, MP3 תומך בקצב העברת נתונים משתנה, שיכול לדחוס את האודיו עוד יותר. שתי הטכניקות גורמות לאובדן מידע ועלולות לפגוע באיכות. לדוגמה, רוב האנשים יכולים להבחין בהבדל בין מוזיקת MP3 מקודדת בקצב העברת נתונים של 96kbps או 128kbps.

בצורות דחיסה אחרות, פרמטרים אחרים יוגבלו.

‫MULAW (נקרא גם μ-law או uLaw) הוא קידוד PCM של 8 ביט, שבו האמפליטודה של הדגימה עוברת אפנון לוגריתמי ולא ליניארי. כתוצאה מכך, uLaw מקטין את הטווח הדינמי האפקטיבי של האודיו שנדחס. למרות ש-uLaw הוצג כדי לבצע אופטימיזציה ספציפית לקידוד של דיבור בניגוד לסוגים אחרים של אודיו, אודיו דחוס של uLaw ב-8 ביט עדיין נחות בהרבה מאודיו לא דחוס של LINEAR16 ב-16 ביט (PCM).

‫AMR ו-AMR_WB מבצעים אפנון של דגימת האודיו המקודדת על ידי הוספת קצב העברת נתונים משתנה לדגימת האודיו של המקור.

ממשק Cloud Speech-to-Text API תומך בכמה פורמטים עם אובדן נתונים, אבל אם יש לכם שליטה באודיו המקורי, כדאי להימנע מהם. יכול להיות שהסרת נתונים כאלה באמצעות דחיסה עם אובדן נתונים לא תשפיע באופן מורגש על האודיו כפי שנשמע לאוזן האנושית, אבל אובדן של נתונים כאלה למנוע לזיהוי דיבור עלול לפגוע באופן משמעותי בדיוק הזיהוי.