The increase in the rates paid by streaming services to copyright holders was just too much for Live365. They abruptly closed down recently leaving we broadcasters in a bit of a tizzy.
I’m working to find a replacement and should have something up in a day or so. Please stay tuned here for updates.
The increase in the rates paid by streaming services to copyright holders was just too much for Live365. They abruptly closed down recently leaving we broadcasters in a bit of a tizzy.
I’m working to find a replacement and should have something up in a day or so. Please stay tuned here for updates.
A long time ago… in a digital media file library far away… I was SURE that I had gone through my entire library and performed level ‘normalization’.
For those that are not familiar with the term, ‘normalization’ refers to the process of adjusting the ‘loudness’ of each track to a standard level. This is actually much more difficult that it may sound (pun not intended); when done well it’s much more than just measuring the levels and adjusting them up or down to reach a standard value. The human ear is a decidedly non-linear device (It’s actually performs much more like an log() function but that’s for a different post) that has varying sensitivity across the range of audio frequencies. The perceived effect of this is that two tones recorded at the same ‘level’ may not have the same ‘loudness’.
The simplest form of normalization simply subtracts the highest recording level within a track from an target level. It then boosts the level of the entire track by that amount so the peaks hit the target level. All sections (and frequencies) of the track are boosted equally. This approach does nothing to compensate for wide variations within the track but it does usually prevent listeners from running to twist the volume knob for every track.
I use mp3gain to perform normalization of tracks in my library. At it’s default settings mp3gain achieves a very conservative standard level of 89dB. It also does an analysis of the audio data and compensates for the perceived loudness of the track. Mp3gain does not modify the original audio data; it stores the the adjustment factor within an ID3 tag. Audio players that recognize the REPLAY_GAIN (RGAD, or perhaps RVA2 in ID3v2.4 (and the XRVA)tag for 2.3 compatibility)) ID3 tag will automatically apply the factor during playback to create a ‘normalized’ playback.
While listening to my Christmas playlist I noticed several tracks that were dramatically louder than the majority of the others. After a bit of sleuthing I discovered that a great many of my library tracks had not been normalized – DOH!
One of my New Year’s resolutions: NORMALIZE ALL TRACKS PRIOR TO AIR!
In the first part of this series I explained how to build and configure the Music Player Daemon (MPD) for use with Live365. In this installment I’ll describe how to send the song metadata (Title, Artist, Album). This is a requirement for ‘live’ mode broadcasters; if you do not send this data your station will not be listed in the directory.
When you run a Live365 station in ‘basic’ mode they pull the song metadata directly from the ID3 tags in your MP3 files. Most MP3 streams include this info. within the stream itself so that it can be displayed by the player software. Live365 does not extract this data from the stream you feed to them. Live365 provides an API (application program interface) that allows you to feed the data to them separate from the music stream. Continue reading Build a Live365 station using Linux – Part 2 (Song Data)→
Digital Media and whatever else flows through my head…
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server