ReplayGain and Transcoding

[n8gray]

Hi all,

I’ve given up on waiting for Roku to support ReplayGain. I think they’re just never going to do it. Still, I’m not happy with the idea of permanently altering my files with aacgain or whatnot. It occurs to me, though, that an easy solution would be to transcode mp3->mp3, aac->aac, etc. using aacgain as a transcoder. In other words, run aacgain once beforehand just to tag each track with its volume level, then run it again at playback time altering the actual volume as a transcode step. That way the original file data is preserved for players that are smart, but players that are dumb (the soundbridge) get volume-leveling done on the server side.

AFAIK Firefly can’t currently transcode to anything but wav, which causes me a bit of a problem. Is this something you would consider changing? I’m willing to hack some code if you’ll point me in the right direction.

🙂

[n8gray]

By the way, I should mention that transcoding to .wav is no good — my wireless network can’t handle it.

[fizze]

hm, so you’re running on a weak 802.11b link?

well technically your proposal should work. albeit not with the current releases.
it might work with aac though, but deffo not for mp3.
there are a few filetypes that firefly just wont decode atm 😉

[rpedde]

@n8gray wrote:

Hi all,
AFAIK Firefly can’t currently transcode to anything but wav, which causes me a bit of a problem. Is this something you would consider changing? I’m willing to hack some code if you’ll point me in the right direction.

🙂

Yeah, but hte right way is hard.

The easy, sloppy way is to hack up ssc-script. In plugins.c, it sets the header type to “audio/wav”, change that to “audio/mp3”, and fix the script (mt-daapd-ssc.sh) to emit mp3 rather than wav.

That kinda sucks, but that would work. Won’t work for ssc-wma, or ssc-ffmpeg, but it will get you in the right direction. Errr… so long as you are using unix, not windows, I should say.

– Ron

[n8gray]

Ah, interesting! Hardcoding mp3 wouldn’t work for me since I’m streaming mp3 and aac, but it wouldn’t be hard to query the plugin for the type of file it will produce.

[rpedde]

@n8gray wrote:

Ah, interesting! Hardcoding mp3 wouldn’t work for me since I’m streaming mp3 and aac, but it wouldn’t be hard to query the plugin for the type of file it will produce.

The “righter” way would be a plugin system that offered to convert to or from fixed types… plugins would offer to convert to or from one format to another and a solver would decide the best path to convert from what you have to what you want, then pipeline the necessary plugin modules and let it rip.

But there are file abstraction issues to work on, plus some plugins only work for seekable file handles, etc, etc.

It’s a not-easy issue. I may just hack in a wav-to-mp3 module and have an option to transcode to either wav or mp3, and that’s it. Probably a wrong way to fix it, but might be considerably easier than the right way.

— Ron

[eschoeller]

Agreed. Transcoding to wav and listening over a slow internet connection (over an SSH tunnel for instance) or over a slow wireless connection sucks.

With the new changes to the plugin system is transcoding to wav any easier? I’d like to run two servers actually … one that transcodes to wav, one to 320kbps MP3.

What are the chances having these transcoding plugins read replaygain tags and transcoding to normalize the audio output? I listen to music when I sleep and it always sucks when a loud song comes on and I’m suddenly awake at 3AM for no reason ….

[rpedde]

@eschoeller wrote:

Agreed. Transcoding to wav and listening over a slow internet connection (over an SSH tunnel for instance) or over a slow wireless connection sucks.

With the new changes to the plugin system is transcoding to wav any easier? I’d like to run two servers actually … one that transcodes to wav, one to 320kbps MP3.

What are the chances having these transcoding plugins read replaygain tags and transcoding to normalize the audio output? I listen to music when I sleep and it always sucks when a loud song comes on and I’m suddenly awake at 3AM for no reason ….

The script based transcoder should work automagically, assuming that the wav transcoder understands replaygain.

Not sure which of the transcode applications (flac, alac, oggdec) support those or not right now, though.

[eschoeller]

So, in the past I have used the ssc script, but now with newer versions it seems there is a plugin that gets used instead.

Are these both one-in-the-same or entirely different from each other? It seems that you’re saying that the script based transcoder may be able to benefit from replaygain but the plugin version can not?

What is the easiest way to switch between the two methods?

I have in my conf file:
[general]
ssc_codectypes = flac
ssc_prog = /usr/bin/mt-daapd-ssc.sh
[plugins]
plugin_dir = /usr/share/mt-daapd/plugins
plugins = rsp.so,ssc-script.so

[rpedde]

@eschoeller wrote:

Are these both one-in-the-same or entirely different from each other?

They are the same. It’s just that the script transcoder got converted to a plug-in.

So the same ssc_codectypes and ssc_script apply. If you use the default transcoding script (mt-daapd-ssc.sh), then it uses oggdec and flac command line decoders.

Since flac 1.1.1, there has been a “–apply-replaygain-which-is-not-lossless” option which will decode with replaygain.

Not sure about ogg.

[Author]

Posts