You are here: Home » Topic » Transcoding to lossy format for bandwidth reasons

Transcoding to lossy format for bandwidth reasons

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Feature Requests Transcoding to lossy format for bandwidth reasons

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #1630
    polpo
    Participant

    I like to use Firefly to listen to my home audio library while I’m at work. This works great for MP3, AAC, and OGG, but many of my files are stored as flac and this uses too much bandwidth. Having ssc transcode to one or any of the above formats would be quite beneficial.

    I’ve tried hacking this in to both script- and plugin-based SSC but it seems like too much of the code is built around providing WAV data to make quick work of it.

    #12067
    rpedde
    Participant

    @polpo wrote:

    I like to use Firefly to listen to my home audio library while I’m at work. This works great for MP3, AAC, and OGG, but many of my files are stored as flac and this uses too much bandwidth. Having ssc transcode to one or any of the above formats would be quite beneficial.

    I’ve tried hacking this in to both script- and plugin-based SSC but it seems like too much of the code is built around providing WAV data to make quick work of it.

    True. I had at some point toyed with the idea of doing anything to anything, but it seems like mp3 is the lowest common denominator, so I think I will end up with a mp3 transcode target at some point.

    — Ron

    #12068
    emma_peel
    Participant

    Oh yeah, this functionality would be great.

    The players that don’t support .ogg & .flac, do not require more than .mp3.

    That would be really better for the bandwidth, especially while tunneling over internet. 😉

    #12069
    ginormous
    Participant

    This would be great. My coworker tunnels his home collection into work network. He has resisted ripping his CDs to Flac because he doesn’t want kill his bandwidth when he tunnels. I’d probably tunnel as well if I could transcode into mp3 (since collection is largely Flac).

    #12070
    hypatia
    Guest

    I’d like to add my vote for this too.

    What exactly has to be done to make this work? Rewrite wavstreamer as mp3streamer?

    Thanks for a media server,
    hypatia

    #12071
    rpedde
    Participant

    @hypatia wrote:

    I’d like to add my vote for this too.

    What exactly has to be done to make this work? Rewrite wavstreamer as mp3streamer?

    Thanks for a media server,
    hypatia

    That’s almost all. The cheap answer, if you wanted to *just* do mp3, and didn’t want to be able to choose which, would be to change the transcode script mt-daapd-ssc.sh so that it converted to .mp3 by using lame or something after converting to wav, then changing line 507 of plugin.c to emit a header type of “audio/mp3” rather than “audio/wav”.

    But I’d like something that could choose to transcode to mp3 or wav depending on connection IP, so that when you connected via a tunnel from work, it would automatically transcode to mp3, but transcoded to wav at home. Something more integrated like that. But the above would work if that’s what you wanted all the time.

    — Ron

    #12072
    Anonymous
    Inactive

    @rpedde wrote:

    …The cheap answer, if you wanted to *just* do mp3, and didn’t want to be able to choose which, would be to change the transcode script mt-daapd-ssc.sh so that it converted to .mp3 by using lame or something after converting to wav, then changing line 507 of plugin.c to emit a header type of “audio/mp3” rather than “audio/wav”….

    Is this still a legit way of getting firefly to stream transcoded mp3? I grabbed the source and can’t locate the file plugin.c nor can I find ‘audio/wav’ in anywhere is the source code. Am I not looking in the right place?

    #12073
    fizze
    Participant

    Which source did you grab? 😉

    The source sure hasn’t change much since late 2007.

    #12074
    Anonymous
    Inactive

    I grabbed the lastest stable release from source forge: 0.2.4.2. I grabbed it from this page: http://sourceforge.net/project/showfiles.php?group_id=98211&package_id=105189

    It says that the release date for 0.2.4.2 is April, 2008. Based on your comment should I be using the older stable release from October 2007?

    #12075
    fizze
    Participant

    Yes. 0.2.4.* is ancient, there were just some ancient security bugfixes applied to an ancient codebase.
    You can get access to the recent sources thrugh trac @ http://trac.fireflymediaserver.org/

    #12076
    Anonymous
    Inactive

    I’m new to the forums, but here’s a very bad hack to get Firefly Media Server to automatically transcode your library to a lower bitrate, lossy format that iTunes and other DAAP clients can play. Note that this assumes you have high-bitrate mp3s (say, 320 kbps, which my library is in), and you want to transcode to very low bitrate mp3s (say, 96 kbps, to play on your smartphone over crummy EV-DO speeds)

    This involves three steps:
    1) Modify the mt-daapd-ssc.sh script to include mp3 output support
    2) Modify the plugins.c file to change the headers sent to the client
    3) Modify the rsp.c and out-daap-proto.c files to change the database information sent to the client

    Step 1:
    In mt-daapd-ssc.sh, add an mp3_file() function that pipes the file through lame, encode it at 96 kbps (which is about as high as my mobile phone can stream without getting choppy), and spit it back out.

    mp3_file() {
    cat "$FILE" | lame --mp3input --preset 96 - -
    }

    I know the LAME fanatics will surely have a better set of command-line options; especially in terms of quality of conversion. Since this only needs to be done in realtime, you can use pretty high conversion quality settings.

    If you’ve got non-mp3 formats, you’ll have to use something else to either decode to a middleman wave file that can then be piped through lame (without the –mp3input, of course), or maybe find a program that can transcode straight to mp3.

    Make sure to call the function in the body of the script. My library has all mp3s, so my script only has the mp3 function and call for it. But again, you could still test for other formats and transcode them, too.

    Step 2:
    in plugin.c, change “audio/wav” to “audio/mp3” so Firefly emits the correct header. Also, we need to send out a content-length header, so change:


    if(!offset){
    ws_writefd(pwsc,"HTTP/1.1 200 OKrn");
    }

    to


    if(!offset){
    ws_addresponseheader(pwsc,"Content-Length","%ld",(long)((pmp3->song_length)* 12));
    ws_writefd(pwsc,"HTTP/1.1 200 OKrn");
    }

    This is a very, very, very bad hack, but I don’t know how else to know the filesize of the file until it’s been transcoded, and I want playback to begin immediately. I hope someone else on the forums who’s more familiar with mp3 file structure (and isn’t a beginning C/C++ student like me) can help.

    Anyway, pmp3->song_length * 12 is an overestimate of the filesize of an mp3 file encoded at 96 kbps. If the estimate is too low, your client won’t download the whole track, and the song will cut off. If the estimate is too high, certainly clients might not be able to play the end of the song (because they’re waiting for data that isn’t there). I haven’t had any problems with WiFiTunes on my WM6 phone, or iTunes 8 on Windows.

    Even worse off, I haven’t bothered changing the Content-Range if there *is* an offset value — iTunes still lets you scrub, but it has to progressively download the track first. I never scrub my tracks, so it wasn’t a priority.

    Step 3:
    in rsp.c and out-daap-proto.c, change all

    transcode = _ppi->should_transcode(pwsc,row[37]);

    to


    // transcode = _ppi->should_transcode(pwsc,row[37]);
    transcode = 0;

    There are two of these in the daap-proto.c and one in the rsp.c that need to be changed.

    This prevents firefly from changing the “Kind” and “Type” formats from their original to “WAV audio” and such. However, again, this is a hack — if you’ve got a non-mp3 file, its type will be left as “mpeg4” or whatever (when it should be converted to mp3). This is easier than changing all the XL output code to emit “mp3” and such.

    If this is a feature that a lot of people are looking for, some more major modifications would have to be made to the source code to make this more robust, as Ron noted.

    Perhaps a global “transcode to mp3” option in the config file, with an accompanying “transcoded bitrate” option, that would pipe the output of the mt-daapd-ssc.sh through lame (while leaving the conversion to wave intact), plus calculating the exact file size (easily done if you know anything about mp3 files, which I don’t) to send in the headers and to iTunes (thank god it doesn’t actually play this music back at the bitrate the library thinks it’s encoded at…). It’s not hard, but someone with more knowledge of the source for this program would have to spend a solid afternoon tinkering.

    And the idea of testing the IP address (to see if it’s local or remote) is definitely brilliant.

    But at least now we have a laundry list of things needed to be changed, and a poor hack to show it can be done fairly easily.

Viewing 11 posts - 1 through 11 (of 11 total)
  • The forum ‘Feature Requests’ is closed to new topics and replies.