ffmpeg + sox transcoding and gapless playback

[krutsch]

Hi All,

I am using MinimServer 0.8.4 / Streamer 0.5.24 w/ ffmpeg + libsoxr (both build from sources, this week).

I am streaming to Volumio 1.55 on a Cubox-I.

Everything works when I transcode to WAV/24, but I hear a very brief tick or pop when transitioning to the next track. So, technically, I would say that gapless works, but the tick is there and, of course, it drives me crazy.

If I disable transcoding, and just feed ALAC or FLAC to the renderer, directly, there is NO tick or pop - completely smooth.

I am wondering if anyone else is experiencing sound artifacts when transcoding to WAV/24?

Thanks, in advance.

[simoncn]

Depending on how the renderer implements gapless transitions between tracks, it is possible that transcoding could cause an issue because of a slightly longer delay between MinimServer receiving the stream request and sending the start of the streamed data.

Are you using flac:wav24 (transcoding using MinimStreamer only) or are you using some other transcoding setting that does transcoding using ffmpeg and libsoxr? If it is the latter, try the former to see if that helps.

You could also try converting the album to wav24 using an offline converter such as dBpoweramp. Do you still get the problem?

If the problem is related to a slightly longer delay, the only solution will be a change to the renderer to handle this correctly.

[krutsch]

(29-04-2016 21:50)simoncn Wrote:  Depending on how the renderer implements gapless transitions between tracks, it is possible that transcoding could cause an issue because of a slightly longer delay between MinimServer receiving the stream request and sending the start of the streamed data.

Are you using flac:wav24 (transcoding using MinimStreamer only) or are you using some other transcoding setting that does transcoding using ffmpeg and libsoxr? If it is the latter, try the former to see if that helps.

You could also try converting the album to wav24 using an offline converter such as dBpoweramp. Do you still get the problem?

If the problem is related to a slightly longer delay, the only solution will be a change to the renderer to handle this correctly.

Thanks for the reply. I am using flac:wav24 with MinimStreamer only.

I've just finished converting my DLNA library to AIFF, across the board, and I will re-try this with no conversion (I am on vacation now :-).

I was using a Bryston BDP-1 as a renderer, but that device cannot handle native ALAC or AAC via streaming, unbelievably, as it's using gmedia-render-resurrect, which is hopelessly inadequate.

I've moved onto a Volumio solution, using upmpdci + mpd, which can handle everything I throw at it, with seamless playback.

[krutsch]

(29-04-2016 21:50)simoncn Wrote:  Depending on how the renderer implements gapless transitions between tracks, it is possible that transcoding could cause an issue because of a slightly longer delay between MinimServer receiving the stream request and sending the start of the streamed data.

...

If the problem is related to a slightly longer delay, the only solution will be a change to the renderer to handle this correctly.

I've decided that this is what's happening... I tested this with one track that gaplessly transitions into another that is a large file (20 min. song) and the delay becomes more noticeable as the Mac Mini loads, transcodes and ships the file across the network. If you simply RW and try again, everything works fine because (presumably) the audio files are in local cache.

I could try a faster everything (i.e. local SSD and a faster processor on the Mac Mini -side), but at some point, it's a problem with my renderer not being able to handle certain file types.

Thanks for the suggestion.

[tboooe]

Krutsch, may I please ask where you downloaded the linux version of ffmpeg that supports libsoxr? I seem to be having trouble with this. My intention is to also use libsoxr on a linux machine I have (Ive been doing the same on two other Windows machines I have without any issue).

[krutsch]

(22-05-2016 07:35)tboooe Wrote:  Krutsch, may I please ask where you downloaded the linux version of ffmpeg that supports libsoxr? I seem to be having trouble with this. My intention is to also use libsoxr on a linux machine I have (Ive been doing the same on two other Windows machines I have without any issue).

From sources. I am on a Mac and I used brew to pull down both SoX and FFMpeg.

[krutsch]

(29-04-2016 21:50)simoncn Wrote:  Depending on how the renderer implements gapless transitions between tracks, it is possible that transcoding could cause an issue because of a slightly longer delay between MinimServer receiving the stream request and sending the start of the streamed data.

Are you using flac:wav24 (transcoding using MinimStreamer only) or are you using some other transcoding setting that does transcoding using ffmpeg and libsoxr? If it is the latter, try the former to see if that helps.

You could also try converting the album to wav24 using an offline converter such as dBpoweramp. Do you still get the problem?

If the problem is related to a slightly longer delay, the only solution will be a change to the renderer to handle this correctly.

So, I spent some time testing this out; whether I use ffmpeg or MinmStreamer's internal transcoding for FLAC, I still hear the slightest 'tick' between tracks.

I've since moved my library off of the NAS share onto a Thunderbolt drive directly connected to the Mac Mini running MinimServer, so the storage is as optimized as I can make it (it's fast).

There isn't any delay ... it's just that little tick, which is annoying with Volumio. So, for now I will go back to just native FLAC.

EDIT: also, I tested this with and without BubbleUPnPServer in the mix - same result with two different renderers (Volumio with upmpdci and Bryston BDP-1 with gmediarender-resurrect).

[krutsch]

(25-07-2016 17:54)krutsch Wrote:  

(29-04-2016 21:50)simoncn Wrote:  Depending on how the renderer implements gapless transitions between tracks, it is possible that transcoding could cause an issue because of a slightly longer delay between MinimServer receiving the stream request and sending the start of the streamed data.

Are you using flac:wav24 (transcoding using MinimStreamer only) or are you using some other transcoding setting that does transcoding using ffmpeg and libsoxr? If it is the latter, try the former to see if that helps.

You could also try converting the album to wav24 using an offline converter such as dBpoweramp. Do you still get the problem?


If the problem is related to a slightly longer delay, the only solution will be a change to the renderer to handle this correctly.

So, I spent some time testing this out; whether I use ffmpeg or MinmStreamer's internal transcoding for FLAC, I still hear the slightest 'tick' between tracks.

I've since moved my library off of the NAS share onto a Thunderbolt drive directly connected to the Mac Mini running MinimServer, so the storage is as optimized as I can make it (it's fast).

There isn't any delay ... it's just that little tick, which is annoying with Volumio. So, for now I will go back to just native FLAC.

EDIT: also, I tested this with and without BubbleUPnPServer in the mix - same result with two different renderers (Volumio with upmpdci and Bryston BDP-1 with gmediarender-resurrect).

I spent some time looking into this, again. I manually converted some FLAC tracks to WAV using XLD in my Mac. Played this through Minim and their isn't even the slightest tick/pop when transitioning between gapless tracks.

The same tracks as FLAC, converted on-the-fly to WAV with Minim exhibit the behavior I describe above. This seems to be the case regardless of whether I use the Minim converter or FFMPeg (i.e. flac:wav24. It also doesn't matter whether I specify wav24 or just wav.

Again, there is no delay, just a slight tick sound at the point of track transition. This occurs across a variety of gapless tracks.

I also tested this on two different renderers: Volumio 1.55 running on a Cubox-i4Pro and a Bryston BDP-1 in DLNA mode (runs gmediarender). Same behavior on both renderers.

Is it possible that something is being dropped off the end of the converted audio stream? It almost sounds like a sample is missing at the end of the previous/next track, causing the slight tick.

[simoncn]

(23-10-2016 05:45)krutsch Wrote:  Is it possible that something is being dropped off the end of the converted audio stream? It almost sounds like a sample is missing at the end of the previous/next track, causing the slight tick.

I have tested this many times and I have never found a difference between the output from on-the-fly conversion and offline conversion.

You can check this for yourself by getting the URL for the on-the-fly converted stream using a control point that can show stream URLs (e.g., BubbleUPnP or Kinsky Windows), then using a tool such as curl or wget to download the stream from that URL and save it as a file. You can then use a file comparison program to see whether the contents of this file are different from the offline converted file.

[krutsch]

(23-10-2016 21:01)simoncn Wrote:  I have tested this many times and I have never found a difference between the output from on-the-fly conversion and offline conversion.

I believe you... so, is this:

a) a network latency problem,

b) a CPU and/or storage performance issue at the server end (I need a faster Mac Mini or faster locally attached storage),

c) a renderer issue (the renderer is waiting too long to request the initial packets for the next song)?

I get it that your answer above was c), but I am struggling with that, simply because there appears to be NO delay between track transitions, that I can hear, with my current setup - just a the addition of a tick/pop.