openbroadcaster / observer

:radio: OBServer Automation, Scheduler, Media Library and Player Manager
https://openbroadcaster.com
148 stars 44 forks source link

Silence Detection on Corrupted Media #82

Open radiorob opened 1 year ago

radiorob commented 1 year ago

Assuming all is working properly with scheduling and playout, there are sometimes gaps and dead air. These instances are few and far between and when we do get silence, we dig into the cause. When initially uploading media, we do some basic crc checking and junk filtering to keep out bad media. Sometimes media gets in that causes silence playout issues.

Solution

1) In >Media Settings, disable all compressed formats and only allow users to upload material in /Ogg/OPUS/Wav/FLAC We can do this now.

2) When uploading, do an additional acoustic check on media to look for erroneous blank spots

3) A CLI tool that can be run on a large media library to check for silence gaps and flag other corrupted conditions not caught in upload tool

Examples of badly encoded media that has silence in the middle or end of recording

Silence detection inside media items Silence detection inside media items gap-in-recording gap-in-recording silence at end of recording silence at end of recording crc check failed crc check failed

ltyndale commented 1 year ago

To be honest, this seems more like a production issue then a problem that the automation system should be worried about. People should not be uploading poor audio. When audio is added to the system it should first be checked to make sure it is good, with proper normalized levels (unlike example 1 and 2 above, where they not only have large silent spots, but it appears that the audio after the silent spot is not normalized to the same level as the audio before the silent spot), no bad spots, properly mixed down to mono in the case of an AM or mono station, its left and right tracks in phase (as opposed to being out of phase and causing silence on the air), and anything else that needs to be done. All of this is part of producing good audio. Once their audio is properly checked for all of this and normalized to whatever normalization standard is set for the station, then ideally an uncompressed BWF (Broadcast Wave Format) file should be what gets uploaded (and preferably checked once the upload is done before it goes to air).

radiorob commented 1 year ago

Correct. Garbage in garbage out. OBVer1, terrible uptime, nonstop troubleshooting until we dumped all the corrupted mp3 and only used Ogg. That made a huge difference. +1 for best practices at station. Real world, some users (me) are just plain lazy\busy to check levels, include all metadata or even have an understanding of the codec (esp Video) are using in a rush to get material on air. First thing I try when evaluating a radio system is to rename a .doc file to .mp3 and then see if I can upload and ingest into media library. Now we are looking at a future where there is no production, just hit record on cellphone, upload and hope for the best.

ltyndale commented 1 year ago

While I do know it happens, if talking about "best practices" then files encoded as MPEG-1, Layer 3 (also known as MP3's for short) should never be put on the air and stations should actually reject audio if it comes in the MP3 format.  The MP3 format was not developed to be a broadcast format, it was developed as a consumer format.  When it comes to music (this doesn't really apply to straight voice without music) the encoding to MP3 strips out a lot of factors from the audio that many broadcast audio processors look for when processing audio before it hits the transmitter. That is partly why you can often tell if something was sourced from an MP3 when listening to a track on the air, even in cases where the MP3 was encoded at a very high bitrate.

If MPEG-1 encoding is being used for over the air radio broadcast then the better format would be to use MPEG-1 Layer 2 (also known as MP2's). This format was developed at the same time as MP3, however it was the version of the codec developed specifically for broadcasting and professional use. It doesn't get as much compression on the files (in other words, the audio files are a little larger then their equivalent in MP3), but the benefit is it doesn't strip out many of the bits of the audio file that many audio processors rely on.

I do agree that if you're using a compressed audio format then OGG / OPUS is definitely the better format to use, it leaves a lot of the shortcomings of MP2 and MP3 behind.

radiorob commented 1 year ago

updated above, right now in new installs, for best practice admins can disable all formats except uncompressed audio. So this is a tool needed for maintenance of large libraries to do this type of check. The CJUC library has over 130K media items, some from old days, early 2000's sound awful mp3@64kb With decent internet these days, no need to be sending around compressed files in an automation system.

radiorob commented 7 months ago

adding support for BWF archival purposes https://github.com/openbroadcaster/observer/issues/166