Transcode WAV header garbage

Help
Stu-e
2011-05-12
2013-05-30
  • Stu-e
    Stu-e
    2011-05-12

    Hi
    Transcoding FLAC audio to WAV produces a WAV file with a few bytes of garbage at the very beginning before the 'RIFF' tag.
    This was discovered using wget to download the transcoded file and viewing the file with hexedit.
    I used the flac application to transcode. If I convert the file offline using flac, the header is clean.
    The garbage is ignored by a Windows Media Player client, but causes problems for an Android client I have, causing it to skip whole files making playback impossible.

    Is this a bug in Mediatomb?

    Stu-e

     
  • BT
    BT
    2011-05-13

    I don't think it's a bug in MediaTomb since it just streams the data returned from the transcoding process. It doesn't manipulate the data, so I don't know where those extra bytes are coming from.

    Most UPnP devices will refuse to play files that are transcoded to WAV via MediaTomb. I believe it's caused by not having the content length of the transcoded file, which is stored in the WAV header. The content length is unknown because MediaTomb uses a named pipe for output.

    Have you tried trancoding to raw PCM? This is what most UPnP devices will accept including my PS3. In my case the output needs to be in 16-bit big endian, otherwise all I get is white noise.

    The following is the transcoding profile that I use for all audio including FLAC:

          <profile name="audio2pcm" enabled="yes" type="external">
            <mimetype>audio/L16</mimetype>
            <accept-url>no</accept-url>
            <first-resource>yes</first-resource>
            <hide-original-resource>yes</hide-original-resource>
            <accept-ogg-theora>no</accept-ogg-theora>
            <sample-frequency>44100</sample-frequency>
            <audio-channels>2</audio-channels>
            <agent command="ffmpeg" arguments="-i %in -acodec pcm_s16be -ab 192k -ar 44100 -ac 2 -f s16be -y %out"/>
            <buffer size="1048576" chunk-size="131072" fill-size="262144"/>
          </profile>
    
     
  • bebopfreak
    bebopfreak
    2011-05-13

    Well, one can do the following simple tests (in linux). How could one explain the behaviour of mediatomb 0.12.0?

    a) flac to wav transcoding:

    flac -dsf -o file.wav  file.flac
    flac -dsf -c file.flac > stdout.wav
    mkfifo /tmp/pipe; cat /tmp/pipe > pipe.wav & flac -dsf -o /tmp/pipe file.flac
    

    all three wav files are equal - so the argument about wrong length doesn't seem to be valid

    b) identity profile:
    - define a file id.sh:

    1
    2
    #!/bin/sh
    cat "$1" > "$2"
    

    - define a simple profile

    ...
          <transcode mimetype="audio/mpeg" using="mpegid"/>
    ...
          <profile name="mpegid" enabled="yes" type="external">
            <mimetype>audio/mpeg</mimetype>
            <accept-url>no</accept-url>
            <first-resource>yes</first-resource>
            <accept-ogg-theora>no</accept-ogg-theora>
            <hide-original-resource>yes</hide-original-resource>
        <agent command="id.sh" arguments="%in %out"/>
        <buffer size="262144" chunk-size="1024" fill-size="16384"/>
          </profile>
    ...
    

    retrieve the content via wget and you get garbage at the beginning of the file.
    (By the way the Android Player is robust enough to play this garbage).
    How can this garbage be explained, if data isn't manipulated by mediatomb?

     
  • BT
    BT
    2011-05-14

    a) MediaTomb doesn't know the content length of the the transcoded file, so it can't send a HTTP content length to the client. This is why you see "Length: unspecified " when using wget to retrieve the stream.

    In your test the "transcoding" is not done "on the fly" like MediaTomb does it. It's done in one go so it's easy to find the content length. This is why many clients will refuse to play a WAV file with an unknown content length, but will happily play a raw PCM.

    I'm certainly no expert, but this is my understanding of the transcoding process as was explained to me by the MediaTomb developers. I could be be completely wrong.

    b) I think you may be right. I did the test and there is some extra bytes or garbage before the ID3 tag. Interestingly if I retrieve the stream with wget and play it with VLC, I can hear pops and skips. If I open the stream URL via VLC, then it plays fine. I have no idea where these bytes are coming from, but I can see how it could cause a problem for some players.

     
  • bebopfreak
    bebopfreak
    2011-05-14

    a) @amak79: you might want to take some more lessons from the developers :-)
    b) is there a chance to find out what's going on, or is this project already dead? Raw PCM isn't a solution for lots of devices and other media servers are able to correctly transcode flac to wav.

     
  • griz
    griz
    2012-09-13

    amak79, you are a genius. Your transcoding profile is the only way one that has been able to let me stream flac files from a crappy little plug computer at full quality in a way that my android phone can understand and play without 'fracturing'. Brilliant.

     
  • griz
    griz
    2012-09-13

    fubar 2000 understands this format too, but, alas, VLC does not.

     
  • BT
    BT
    2012-09-15

    thomgriffiths,

    It's nice to know that it still works. I don't use MediaTomb that often and when I do it's for video only. I'm fairly certain that the profile did work with VLC. I have no idea why it doesn't now. Regardless you would be better off using CIFS (Windows file sharing) or NFS if you're playing shared music on desktop as UPnP doesn't make much sense there.