Flac to MP3 transcodiing results in "choppy" sound

Hi
Running Serviio 6.2 on Windows 7 64 bit, or indeed on Centos 6 64 bit on another machine, playback of audio transcoded from FLAC to MP3 is choppy and I can't fathom out why.

My transcode statement is simple:
<Transcoding>
<Audio targetContainer="mp3" aBitrate="192">
<Matches container="flac" />
</Audio>
</Transcoding>

The resultant MP3 is perfectly playable if I copy it from the transcoded file temp directory to another folder so I can play it back through Serviio as an MP3 without transcoding, so the transcoding output itself appears to be fine. The problem occurs whether I run the renderer on the same machine as Serviio or on a remote machine, which suggest it isn't a network problem (as does the fact that the transcoded MP3 can be played ok). None of the CPU cores are ever more than 40% utilized and there is plenty of free memory even if I double the maximum available to Serviio's VM to 768MB. With Log4J set to TRACE nothing untoward is revealed; the transcoding command used is shown as "C:\appls\java\serviio\bin\\..\lib/ffmpeg.exe -i C:\Music\Test\Flacs\dilvie_-_the_dragonfly.flac -y -ab 192k -ac 2 -f mp3 C:\Windows\TEMP\Serviio\dilvie_-_the_dragonfly-MP3.stf"

All in all, I'm perplexed, especially as I cannot find a report of a similar problem in these forums. What am I missing?
Steve

Hmm

It rather looks like this is a problem with the flac decoding in ffmpeg. Running "C:\appls\java\serviio\bin\\..\lib/ffmpeg.exe -v 9 -loglevel 99 -i C:\Music\Test\Flacs\dilvie_-_the_dragonfly.flac -y -ab 192k -ac 2 -f mp3 C:\Windows\TEMP\Serviio\dilvie_-_the_dragonfly-MP3.stf" shows many messages of the form:

[flac @ 00339320] sample/frame number mismatch in adjacent frames
Last message repeated 27 times

Different renderers behave slightly differently, but in all cases the "choppy" sound sounds like frames are being skipped and tracks certainly last less long than they should. Time for some fun with ffmpeg.

Steve

I've not had time to investigate much more. To debug further, ideally I'd need access to the Serviio code. Lacking this, is there a way of modifying the command line sent to ffmpeg to enable its debugging output while transcoding?

And an obvious question. Is anyone out there successfully transcoding Flac to MP3?

Steve

[zip]

You could try to upgrade to a newer version of FFmpeg

I could and I did to the latest build, sadly with the same results

Steve

[moltra]

Read through this thread about creating a wrapper for ffmpeg on a linux machine.

viewtopic.php?f=5&t=5806&p=42051&hilit=wrapper#p42051

here is the search url

http://forum.serviio.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=wrapper

Here is one for windows.

http://forum.serviio.org/viewtopic.php?f=11&t=2956&p=34000&hilit=wrapper+windows#p34000

Ok, if its of any use to others, here is a less elaborate debug script for windows...

  Code:

@echo off
set BATCH_FILE=%~dp0
pushd %BATCH_FILE%..
set SERVIIO_HOME=%CD%
popd
set FFMPEG_EXE=%SERVIIO_HOME%\lib\ffmpeg.exe
set EXTRA_PARAMS=-v 9 -loglevel 99
%FFMPEG_EXE% %EXTRA_PARAMS% %* 2>>%SERVIIO_HOME%\log\ffmpeg.log


Unfortunately, using this doesn't reveal much more than I've already discovered. I've attached the ffmpeg output below.

I'm still curious to know if any one is successfully transcoding flac to mp3. If so, what version of ffmpeg are you using? Flacs to try can be found at http://samples.mplayerhq.hu/flac/. The one for the output below is http://samples.mplayerhq.hu/flac/dilvie_-_the_dragonfly.flac.

Cheers
Steve

ffmpeg version N-39664-g6bfb304 Copyright (c) 2000-2012 the FFmpeg developers
built on Apr 9 2012 20:32:46 with gcc 4.6.3
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 51. 46.100 / 51. 46.100
libavcodec 54. 14.101 / 54. 14.101
libavformat 54. 3.100 / 54. 3.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 67.101 / 2. 67.101
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 10.100 / 0. 10.100
libpostproc 52. 0.100 / 52. 0.100
[flac @ 0000000000357fd0] Format flac probed with size=2048 and score=50
[NULL @ 0000000000368f40] Max Blocksize: 4608
[NULL @ 0000000000368f40] Max Framesize: 11467
[NULL @ 0000000000368f40] Samplerate: 44100
[NULL @ 0000000000368f40] Channels: 2
[NULL @ 0000000000368f40] Bits: 16
[flac @ 0000000000368f40] Max Blocksize: 4608
[flac @ 0000000000368f40] Max Framesize: 11467
[flac @ 0000000000368f40] Samplerate: 44100
[flac @ 0000000000368f40] Channels: 2
[flac @ 0000000000368f40] Bits: 16
[flac @ 0000000000368f40] sample/frame number mismatch in adjacent frames
Last message repeated 114 times
[flac @ 0000000000357fd0] max_analyze_duration 5000000 reached at 5015510
Input #0, flac, from 'C:\Users\sbrewin.SYN003\Music\Test\Flacs\dilvie_-_the_dragonfly.flac':
Duration: 00:01:05.14, bitrate: 632 kb/s
Stream #0:0, 50, 1/44100: Audio: flac, 44100 Hz, stereo, s16
[flac @ 0000000000368f40] Max Blocksize: 4608
[flac @ 0000000000368f40] Max Framesize: 11467
[flac @ 0000000000368f40] Samplerate: 44100
[flac @ 0000000000368f40] Channels: 2
[flac @ 0000000000368f40] Bits: 16
Output #0, mp3, to 'C:\Windows\TEMP\Serviio\transcoding-temp-616-MP3.stf':
Metadata:
TSSE : Lavf54.3.100
Stream #0:0, 0, 1/90000: Audio: mp3, 44100 Hz, 2 channels, s16, 192 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (flac -> libmp3lame)
Press [q] to stop, [?] for help
[flac @ 0000000000368f40] sample/frame number mismatch in adjacent frames
Last message repeated 161 times
size= 323kB time=00:00:13.71 bitrate= 192.7kbits/s
sample/frame number mismatch in adjacent frames
[flac @ 0000000000368f40] sample/frame number mismatch in adjacent frames
Last message repeated 274 times
size= 661kB time=00:00:28.13 bitrate= 192.4kbits/s
sample/frame number mismatch in adjacent frames
[flac @ 0000000000368f40] sample/frame number mismatch in adjacent frames
Last message repeated 258 times
size= 979kB time=00:00:41.71 bitrate= 192.2kbits/s
sample/frame number mismatch in adjacent frames
[flac @ 0000000000368f40] sample/frame number mismatch in adjacent frames
Last message repeated 258 times
size= 1297kB time=00:00:55.30 bitrate= 192.2kbits/s
sample/frame number mismatch in adjacent frames
[flac @ 0000000000368f40] sample/frame number mismatch in adjacent frames
Last message repeated 168 times
size= 1528kB time=00:01:05.14 bitrate= 192.2kbits/s

video:0kB audio:1528kB global headers:0kB muxing overhead 0.042194%

[zip]

I tried it and it worked (flac -> mp3), some time ago I would not necessarily use the samples from ffmpeg as they are possibly corner case examples or broken files people upload for the ffmpeg team to fix.

Interesting to hear that it did work. Maybe a regression has been introduced somewhere along the line?

I referenced the sample files as they are copyright free and available on the web. Sadly flac > mp3 transcoding doesn't work for me using Serviio regardless of the flac's source.

Interestingly, I've just tried the same flac sources with the same flac > mp3 transcoding on the same hardware using a competitor product. Everything works fine! At least this rules out environmental issues

[zip]

you cold try changing the target bitrate.. change it in the profile

I've tried changing the bitrate. Tried forcing variable and constant bitrates. I've even modified my ffmpeg invocation script so that it invokes Lame directly using the same parameters as the competitor product I referred to previously. All to no avail.

Is it time for a bug report?

I have similar problems to steveB with flac-to-mp3. In my case, in addition to being choppy and scratched, the mp3 apparently plays at 3x speed.

If I reduce the bitrate to 64k it plays at normal speed(!), but it's still full of scratches and artifacts.

Server is FreeBSD with ffmpeg 0.7.1
Client HTC Android with Skifta usings it's built-in player, or UPnPlay using the native android player.

If I copy the transcoded file to the phone it plays without problems.

Reported this as an issue. See https://bitbucket.org/xnejp03/serviio/i ... -in-choppy

[zip]

what is your device? I tried it on my Samsung B series and it works fine.

Progress! I first tried FLAC -> MP3 transcoding with Skifta as the renderer using the profile below:

  Code:

   <Profile id="23" name="Skifta" extendsProfileId="1">
        <Detection>
            <UPnPSearch>
                <ModelName>.*Skifta.*</ModelName>
            </UPnPSearch>
        </Detection>
        <Transcoding>
            <Audio targetContainer="mp3" aBitrate="192">
                <Matches container="flac" />
            </Audio>
        </Transcoding>
    </Profile>

As this resulted in "choppy sound", I decided to rule out Skifta and the network by applying the same profile to dBpoweramp Renaissance with Serviio running on the same machine.
I usually use dBpoweramp Renaissance to play FLACs through an external DAC, which works extremely well. With Serviio reconfigured to send it MP3s I hear similar "choppy sound" to that from Skifta.
Moreover, if I repeat the same tests using a competitor server, both renderers work just fine. These results suggest a problem with Serviio's transcoding.

I have now run a third test, using the Serviio console to apply the Skifta profile to a PlayStation3 for which FLAC -> MP3 transcoding works just fine! As Petr has tested this on his "Samsung B" and there
have been no other reports about this for renderers other than Skifta, it looks as if FLAC -> MP3 transcoding works for most devices, but not all. Unfortunately, the "not all" happens to include the first two devices I tried

Still, it would be good to have Skifta working.

[zip]

There is not much I can do TBH. It might be the way the FFmpeg command is invoked (not sure if you can find out the command line of the competition products). Does it play in VLC (via its UPNP client)?

The competitor product uses Lame directly. As I mentioned in an earlier post I did hack my ffmpeg invocation script to do the same with the same options, which yielded the same "choppy sound". I've never been able to detect VLC in Device Spy or Serviio console, so am not sure how I could write a profile or force it to use a profile. Looking at the Serviio logs I can see the User-Agent header, but a profile based on this is never reported in Serviio console. It may be that it doesn't distinguish between multiple renderers at the same IP. Is this the case? If so, I can reconfigure to stop my default renderer starting as a service.

[zip]

\if you run VLC on the same IP as serviio you should see the IP of the PC in the console, hopefully. Then assign it a profile. You have to go to the playlist menu in VLC to browse UPnP servers.

Did you try a FFmpeg with the latest Lame library? I'm using 3.98, there is 3.99.x now

Yes, VLC plays back a FLAC->MP3 transcribed file just fine. My Lame version is 3.99.5 contained in the ffmpeg 64 bit Windows build downloaded from http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20120409-git-6bfb304-win64-static.7z.

By the way, technically, it isn't Skifta that is having problems, it is Android music player app. invoked by Skifta, which by default this is the vanilla one built into Android. So a workaround may be to try installing another music
player app. Or, if the phone supports it, upgrade to Android 3.1 or above in which FLACs are supported so no transcoding is required.

[zip]

The competitor product uses Lame directly.

Do you know what parameters it's using?