פלטפורמות סטרימינג מטפלות בקבצים שהן מקבלות?

[AK1]

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

היה לי קשה לדמיין שיש מצב שזה נכון, כי זה מקטין את המשמעות של hi-res ומעוות את המוזיקה, אז בהתחלה התווכחתי איתו קצת, ואז בחיפוש מהיר מצאתי סירטון שמסביר את זה. אפשר לדלג על ההקדמה ולקפוץ ל-3:49

הסיבות:

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

אז כשאנחנו שומעים סטרימינג ב-24/192 וחושבים שהגענו לסוף העולם, אולי זה לא בהכרח כך...

==========

תוספת מאוחרת 1:

עכשיו הוא הוסיף לינק להסברים של ספוטיפיי על הנושא.
עכשיו הוא הוסיף לינק להסברים של ספוטיפיי על הנושא, לפיהם הנורמליזציות האמורות אינן מופעלת עבור נגן ה-Web (שבו אני משתמש), וכנראה גם לא עבור standalone streamers. אם הן מופעלות עבור סמארטפונים וטאבלטים זה ממש לא מפריע לי.

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

==========

תוספת מאוחרת 2:

מסתבר שב-Tidal וב-Deezer אפשר לכבות את ה-"Loudness Normalization", אם כי זה שהעלה את הנושא טוען שהחברות משקרות גם בעניין אי-ההפעלה של זה ב-Web, בהתקני צד ג', וגם לאחר כיבוי האופציה.

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

 

[ymym]

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

 

[AK1]

למי שלא שם לב, יש 2 "תוספות מאוחרות" לפוסט הפותח.

 

[arix]

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

נורמליזציה של עוצמת השמע - Spotify

support.spotify.com

 

[AK1]

AK1 , מהבנת הנקרא שלי ב"תוספת מאוחרת" אתה משתמש ב ספוטיפיי ?

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

הם עושים נירמול להכל מראש, ראה מאמר בעברית מספוטיפי לאומנים...

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

 

[arix]

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

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

 

[AK1]

ממש לא, כלומר הם עושים נירמול מכיוון שצד שלישי (הנגנים) אינם עושים נירמול, אז בעצם הם עושים לך "טוב" ע"י נירמול

לא הבנתי: "ממש לא" מה?

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

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

אני מניח שרוב/כל הקבצים שהגיעו לפלטפורמת הסטרימינג היו מ-CDs, ועשו נירמול ממקור PCM 16/44.1 ולא מ-mp3.

לא הגיוני שיחזיקו 2 קבצים אחד עם נירמול והשני בלי נירמול.

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

 

[ליאור]

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

 

[arix]

לא הבנתי: "ממש לא" מה?

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

אני מניח שרוב/כל הקבצים שהגיעו לפלטפורמת הסטרימינג היו מ-CDs, ועשו נירמול ממקור PCM 16/44.1 ולא מ-mp3.

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

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

 

[michael123]

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



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

אני חשבתי שמה שמבצע את הנירמול הזה זה קליינט, ואפשר לכבות את זה (ב-Spotify לפחות). בשרת הם שומרים רק את ה-meta data עם האנליזה של הטראק (ie min max)

 

[Cloudy]

לנרמל קובץ זה לא עניין כ"כ יקר. עוד כשהייתי מעביר CD ל MP3 על פנטיום 150Mhz בשנות התשעים זה לא היה כזה ביג דיל והיום המעבד הכי זול והכי מחורבן שתמצא משאיר לפנטיום ההוא אבק.

 

[AK1]

אני חשבתי שמה שמבצע את הנירמול הזה זה קליינט, ואפשר לכבות את זה (ב-Spotify לפחות). בשרת הם שומרים רק את ה-meta data עם האנליזה של הטראק (ie min max)

הגיוני מאוד

לנרמל קובץ זה לא עניין כ"כ יקר. עוד כשהייתי מעביר CD ל MP3 על פנטיום 150Mhz בשנות התשעים זה לא היה כזה ביג דיל והיום המעבד הכי זול והכי מחורבן שתמצא משאיר לפנטיום ההוא אבק.

אם עושים את זה ב-server side, גם מה שהיה טוחן מעבד עתיק לאבק יכול להיות משמעותי כשצריך לעשות את זה לכל משתמש מבין המי-יודע-כמה משתמשים שיש במקביל.

 

[Cloudy]

אם עושים את זה ב-server side, גם מה שהיה טוחן מעבד עתיק לאבק יכול להיות משמעותי כשצריך לעשות את זה לכל משתמש מבין המי-יודע-כמה משתמשים שיש במקביל.

דווקא התכוונתי שלעשות את זה במכשיר הקצה לא ממש מזיז ל ASIC מודרני.

 

[AK1]

דווקא התכוונתי שלעשות את זה במכשיר הקצה לא ממש מזיז ל ASIC מודרני.

אה, זה ברור

 

[ליאור]

אם עושים את זה ב-server side, גם מה שהיה טוחן מעבד עתיק לאבק יכול להיות משמעותי כשצריך לעשות את זה לכל משתמש מבין המי-יודע-כמה משתמשים שיש במקביל.

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

 

[AK1]

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

אם זה המצב, אז הם היו צריכים להשאיר מקום גם לעותקים מנורמלים וגם לקובץ המקורי, כדי שיוכלו לאפשר מצבים בהם יש להזרים את הקובץ ללא נירמול. נראה הרבה הגיוני להשאיר רק קובץ ללא נירמול ו-meta-data של ממוצע ו-peaks, כמו שמיכאל כתב קודם, ומעבירים את הקובץ וה-meta-data ל-client side, שם אם צריך עושים נירמול ואם לא, לא.

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

גם אם מנרמלים מראש ב-server side ובין אם לא, מדובר בפעם אחת.
אם כן או לא מנרמלים ב-client side, זה פחות או יותר אותו זמן, כך שאין טעם לחסוך בזה.

ובקשר למציאות, נראה לי שאנחנו לא באמת יודעים מהי, אלא רק מנחשים מה יותר סביר.

 

[ליאור]

אני לא מנהל דיון טכני על כיצד לתכנן מערכת סטרימינג.
1. זה המצב, לא "אם".
2. "המציאות" היא שאין לי מושג מה אתה יודע או מה אתה מנחש. המושג שכן יש לי הוא מה שעשינו בחברות שעוסקות בסטרימינג בהן עבדתי כארכיטקט, וכמנהל פיתוח ( +- 10 שנים).

 

[AK1]

אני לא מנהל דיון טכני על כיצד לתכנן מערכת סטרימינג.
1. זה המצב, לא "אם".
2. "המציאות" היא שאין לי מושג מה אתה יודע או מה אתה מנחש. המושג שכן יש לי הוא מה שעשינו בחברות שעוסקות בסטרימינג בהן עבדתי כארכיטקט, וכמנהל פיתוח ( +- 10 שנים).

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

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

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

מה שנותר לי לשאול בשלב זה:

1. האם מה שידוע לך באופן ישיר תקף לגבי ספוטיפיי, חברות ספציפיות נוספות, או כל החברות?
   
   
2. האם מחזיקים גם גירסאות לא מנורמלות, כדי לתמוך במצבים שזה מה שנדרש, או שאין תמיכה אמיתית בזה, וסתם אומרים שזה כך, בספוטיפיי עבור Web וצד ג', בדיזר וטידאל עם האופציה לכבות את זה, וכו'?
   
   
3. מה עושים בקובוז, והאם יש אופציה לכבות את זה שם?
   
   
4. האם הטיפול בקבצים כולל קימפרוס טווח דינאמי?
   
   
5. האם הנירמול של העוצמה (בניגוד לנירמול ה-peaks) כולל רק הקטנה/הגדלה של כל הדגימות באותו פקטור? האם זה שקול להעלאת/הורדת ווליום דיגיטלי?
   
   
6. עד כמה ההבדל בשמיעה בין קובץ מנורמל לקובץ המקורי הוא גדול? האם ניתן לבהחין בו בקלות בהשוואה זה לצד זה (לאחר השוואת ווליום ביניהם באמצעים אנלוגיים) או שנדרשות אוזני זהב אודיופיליות?

 

[ליאור]

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

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

בגדול "מחזור החיים" של קובץ הוא
1. האומן\מי מטעמו מעלה מאסטר לשרת.
2. השרת מפעיל אלגוריתמים לטיפול בקובץ, בד"כ מייצר ממנו כמה קבצים (יכול להגיע להרבה מאוד במקרה ווידאו).
2.1 תהליכים שרצים ברקע מנתחים את המוסיקה לפי מידע שיש להם על המשתמשים ומשבצים אותה ב"רשימות" ("רוק אלטרנטיבי 2024" , "מיוחד לליאור" , "מיילס דיוויס המאוחר" וכו..)
3. מערכת ה CDN מפיצה את הקבצים למיקומים האופטימלים בענן ע"פ:
- גיאוגרפיה (מוסיקה ביפנית בשרתים יפנים, מוסיקה בהינדי בשרתים בהודו וכו..)
- פופולריות של הקטע\אומן (אדל מופצת מהר יותר וביותר עותקים, ליותר מיקומים בעולם).
- מידע על המשתמשים ושאר תהליכי רקע (2.1).


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

 

[AK1]

ראשית, תודה על האינפרומציה!

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

שאלה #1 -- האם אפשר לכבות את הנירמול בקובוז בגישה מדפדפן.

אלגוריתם נירמול בסופו של דבר כן דחוס (במובן של טווח דינאמי ).

אני מבין שהקטנת הממוצע מהווה הקטנה של הטווח הדינאמי, אבל יש כאן שתי אפשרויות:

1. הקטנת כל אחת מהדגימות באותו יחס, באופן אידיאלי זה לבטל את ה-least significant bits, מה שמהווה חלוקה בחזקה של 2, אחרת צריכים לבצע חישובים שמרחיקים את התוצאה מהמקור. בכל מקרה, זה גורם לאיבוד מוחלט של low-level information, בין אם מדובר סיגנל חלש ובין אם בפרטים עדינים בתוך סיגנל חזק יותר
   
   
2. הפעלת אלגוריתם שמקטין את הטווח הדינמי ע"י חיזוק הצלילים החלשים במידה קטנה והולכת ככל שהצליל חזק יותר. במקרה כזה, ה-low-level information לא נעלם אלא להיפך, מוגבר, אבל הרזולוציה של כל הצליל יורדת

שאלה #2 היא האם מבצעים את 1 או את 2 לעיל.


ושאלה #3 היא עד כמה גדול ההבדל בשמיעה בין קובץ מנורמל לקובץ המקורי? האם ניתן להבחין בו בקלות בהשוואה זה לצד זה (לאחר השוואת ווליום ביניהם באמצעים אנלוגיים) או שנדרשות אוזני זהב אודיופיליות?