Gaplessness....

[soundhound]

hello Folks
I looked intently into gapless playback and come to the conclusion
my SONY NS510 Upnp renderer just doesn't do SetNextAVTransportURI,
required for Upnp galess playback.

so I turned to OhMedia for which I have seen various claims of implementing
gapless in an alternate way to Upnp.
Presumably this would have been by running a stream to the renderer.
I understand lossless formats in particular are straightforward to
place back-to-back on a stream. MP3 (and others) not so much, at least without
specialised software up to the task (JRiver Media Centre? didn't work for me)

I turned then to BubbleUPnpServer which can proxy a standard Upnp renderer
as an OhMedia one. And it has an option for gapless playback. Yay!
Yet it doesn't work for me (and the warning documentation link about not working with all renderers gives no clue what it _does_ do).

So I have now turned to MinimServer as I undertand it at least handles streaming.
Additionally, internet forum posts abound with assertions of gapless success with it.

So my question is: does MinimServer/MinimStreamer provide gapless by streaming rather than Upnp's SetNextAVTransportURI?
If not, does anyone know what the issues with gapless/streaming are?
I am a programmer and am so frustrated with this situation that still endures after
decades of malfunctioning software (as witnessed by internet forums
I have read) that I am very willing to tackle the problem.
But of course if it was easy it would have been done by now, which is not the case.

thanks...

[simoncn]

MinimServer fully supports gapless playback if and only if the control point and renderer both support this.

To support gapless playback, the renderer must initiate streaming of the next track before it has finished playing the current track. This can be done by the renderer correctly implementing SetNextAVTransportURI or by the renderer natively implementing the OpenHome renderer protocol. As your Sony renderer doesn't do either of these, it is not possible for the control point or the server (or BubbleUPnPServer's software wrapper for the renderer) to compensate for this deficiency.

[Cebolla]

(05-07-2019 17:12)soundhound Wrote:  I looked intently into gapless playback and come to the conclusion
my SONY NS510 Upnp renderer just doesn't do SetNextAVTransportURI,
required for Upnp galess playback.

so I turned to OhMedia for which I have seen various claims of implementing
gapless in an alternate way to Upnp.
Presumably this would have been by running a stream to the renderer.
I understand lossless formats in particular are straightforward to
place back-to-back on a stream. MP3 (and others) not so much, at least without
specialised software up to the task (JRiver Media Centre? didn't work for me)

I turned then to BubbleUPnpServer which can proxy a standard Upnp renderer
as an OhMedia one. And it has an option for gapless playback. Yay!
Yet it doesn't work for me (and the warning documentation link about not working with all renderers gives no clue what it _does_ do).

You appear to have misunderstood how OpenHome (aka UPnP with Linn extensions) streaming works, what (if any) involvement the UPnP media server has with the renderer implementing gapless playback and what the BubbleUPnP Server's association with OpenHome is.


OpenHome renderers exist separately to standard UPnP renderers and use a different incompatible mechanism for providing audio file streaming, which includes the implementation of gapless playback. The main difference is that with OpenHome streaming it's the renderer that owns the current playlist; whereas with standard UPnP streaming it's the control point that owns the current playlist.

Hence the reason why an OpenHome renderer should be able to easily implement gapless playback support on its own, as it does not require the OpenHome control point to tell it what track to fetch next from the UPnP media server every time, during playback of the current playlist. Compare that to the standard UPnP renderer, which requires the SetNextAVTransportURI UPnP AVTransport action to be sent from the UPnP control point every time (and in time) to play the next track in the playlist, in order to implement gapless.

Some streamers support both OpenHome and standard UPnP streaming, so contain both a standard UPnP renderer and an OpenHome renderer, but the majority only support standard UPnP streaming and therefore only have a standard UPnP renderer - such as your Sony NS510 streamer.


The UPnP media server, such as MinimServer, has a more passive role in all of this and delivers to the renderer the audio files that the renderer has requested, as discrete separate streams. All the UPnP media server needs to do in order for standard UPnP renderers and OpenHome renderers to play gaplessly, is allow more than at least one audio file to be streamed from it at the same time (still as separate streams) by the requesting renderer.
Note, the UPnP media server does not get any knowledge of the current playlist, so it would not be able to know which audio files to, as you said, "place back to back" on a long single stream (presumably to help implement gapless playback), even if it could!


The BubbleUPnP Server's Create an OpenHome renderer function is there to allow standard UPnP renderers to be controlled by OpenHome control points, so provides a bridge between the two incompatible streaming technologies. Its main jobs are to:

- Maintain the current playlist for the 'OpenHome renderer' created for the associated standard UPnP renderer;

- Provide connectivity and proxying for the TIDAL & Qobuz online streaming services as supported by OpenHome;

- Translate any received OpenHome control point commands into standard UPnP control point commands (UPnP AVTransport actions) and send them out to the associated standard UPnP renderer. This includes translating one received 'play current playlist' OpenHome control point command into several (depending on the number of tracks in the playlist) SetNextAVTransportURI actions and, at the appropriate times, sending them to the associated UPnP renderer. Of course, this can only work if the associated UPnP renderer supports the SetNextAVTransportURI action in the first place!

The tick box for gapless support by the BubbleUPnP Server is only enabled if the associated UPnP renderer advertises support for the SetNextAVTransportURI action and is otherwise greyed out. The reason why the user has to manually set gapless playback support is that some UPnP renderers claiming SetNextAVTransportURI action support have been found to be faulty, leading to playback problems if the action is sent.

[tarnkappe]

you could try the Logitec Media Server with its upnp bridge plugin. AFAIK this does one single stream to the client, too, without any track changes. You can play from other upnp servers like minimserver or use the LMS as source.

[Cebolla]

(10-07-2019 20:43)tarnkappe Wrote:  you could try the Logitec Media Server with its upnp bridge plugin. AFAIK this does one single stream to the client, too, without any track changes. You can play from other upnp servers like minimserver or use the LMS as source.

Oh dear, one of the main points of my post (which admittedly did ramble on a bit, so perhaps it could have been missed) was that none of the "specialised software" methods mentioned by the OP (JRiver Media Center, OpenHome streaming & BubbleUPnP Server), provide a single audio stream (built from the current playlist's tracks) to the renderer over the network, so cannot be used to correct a renderer's lack of gapless playback support!

Also, you are almost correct about the UPnP/DLNA bridge LMS plugin. It normally uses SetNextAVTransportURI actions to get its associated UPnP renderers to play gaplessly, so this most certainly gets the renderer to play one stream per track in the current playlist. In fact this is no different to how the BubbleUPnP Server's Create an OpenHome renderer function handles gapless for its associated UPnP renderers, but of course the UPnP/DLNA bridge plugin's main purpose is to allow UPnP renderers to be used with LMS/Squeezebox controller apps rather than OpenHome controller apps.

However, unlike the BubbleUPnP Server, the UPnP/DLNA bridge plugin does have an optional special gapless playback & crossfade support function, named Flow, which does provide the single audio stream from the current playlist of tracks, you mentioned.


BTW, due to length of my last post, I decided to wait for a response from the OP before suggesting any specialised software that does combine all the tracks in the current playlist into a continuous single stream, like the UPnP/DLNA bridge LMS plugin's Flow option, to help UPnP renderers that don't do gapless.

Given that you have already mentioned one of them I may as well add to it now. So, apart from LMS and the UPnP/DLNA bridge plugin with the Flow option set, the only other application I can think of (and is a Windows only solution) that can provide a continuous audio stream to a UPnP renderer, is the foobar2000 audio file player with the foo_out_upnp fb2k plugin component.

[simoncn]

Thanks for this excellent summary of the causes of this issue and possible solutions!

[MarmiteSandwich]

On the subject of renderers which do/don't support gapless. I have recently changed my renderer from mpd on a Raspberry Pi (£50) to a Cambridge Audio CXN V2 (£700). In both cases I observed that for some albums where gaplessness is important, although the decoded output to the DAC is nearly gapless, a very frustrating micro-gap can be heard, specifically with aac files in .m4a format. I estimated it to be c60ms. The same albums/tracks when encoded with flac did not display this characteristic.

I managed to get Cambridge Audio to admit that it was an audible flaw in .m4a/aac decoding and they have agreed to solve it in a forthcoming firmware release. That was very impressive, I thought.

Meanwhile, I had tracked the problem, via the developer of mpd to a "bug" in ffmpeg, a piece of software which is widely used in audio encoding/decoding. I suspect that CA are one user of ffmpeg. I registered it with ffmpeg as a bug, and recently received a reply which rather surprised me. It turns out that .m4a/aac files created with iTunes are not supported by ffmpeg for gapless processing. Something to do with null samples in the data at the beginning and end of the track, and how to tell the decoder how many there are. iTunes uses a iTunSMPB tag in the metadata to do this and ffmpeg doesn't recognise this tag. More info which I don't understand here.

Since CA have said they will fix the problem, I am not overly concerned, but I would be interested if anyone can recommend a way of converting these iTunes files to something which ffmpeg will play truly gaplessly. Somebody at ffmpeg was very helpful about this, but I couldn't understand the response.
Marmite

[simbun]

Lossy support is a nightmare; MP3 with ID3v2.3 is probably best supported, but it's horrible, everything else I've had problems with.

MP3 and AAC don't natively support gapless playback (in the spec), but LAME came up with a way to support it in MP3 as did Apple in AAC (and maybe other sources based on the bug tracker you linked to), but it only works if all decoders support it too.

Are you tied to iTunes, and do you have lossless versions of those lossy AAC files you have?
A simpler option would/should be OGG Vorbis as gapless playback is built into the spec, but it's not supported by iTunes.

At the end of the day you'll have to try them all (MP3, AAC, Vorbis) with each hardware/software player you have, to work out what's best for you.

I've settled on OGG Vorbis for portable use (FLAC for everything else), and even then my Fiio M5 (used only for running) doesn't show any Genre!

[MarmiteSandwich]

(21-09-2021 12:03)simbun Wrote:  Lossy support is a nightmare; MP3 with ID3v2.3 is probably best supported, but it's horrible, everything else I've had problems with.

It's good to know I'm not the only one who has these problems.

(21-09-2021 12:03)simbun Wrote:  Are you tied to iTunes, and do you have lossless versions of those lossy AAC files you have?

Not tied to iTunes, but that's what the 1000 or so CDs/flac downloads were encoded with.

(21-09-2021 12:03)simbun Wrote:  A simpler option would/should be OGG Vorbis as gapless playback is built into the spec, but it's not supported by iTunes.

I would switch to another format, but it would mean re-ripping everything. Then there is the question of which player will work with it.

(21-09-2021 12:03)simbun Wrote:  At the end of the day you'll have to try them all (MP3, AAC, Vorbis) with each hardware/software player you have, to work out what's best for you.

I copy the master library to my phone, the car and a second pi/mpd, so I need the solution to work across all of these. I have found that flac works in all cases (in iTunes' m4a wrapper), so I am settled on just re-ripping those albums where this problem presents itself. I probably don't have enough space to re-rip everything in flac, apart from the work in updating metadata to my standards. It doesn't seem to be all albums that are affected, even if they have tracks which segue. Probably just a function of how many null samples there happen to be at the beginning/end of a track.

I was just hoping I could avoid re-ripping by running some kind of utility on all my aac files to add/remove the necessary tags which show the relevant length/null information. The iTunSMPB tag is definitely there, the question is, what other tags are needed for players/software such as mpd to drop the nulls successfully?

Hopefully,
Marmite

[skeptic Mike]

(20-09-2021 17:31)MarmiteSandwich Wrote:  On the subject of renderers which do/don't support gapless. I have recently changed my renderer from mpd on a Raspberry Pi (£50) to a Cambridge Audio CXN V2 (£700). In both cases I observed that for some albums where gaplessness is important, although the decoded output to the DAC is nearly gapless, a very frustrating micro-gap can be heard, specifically with aac files in .m4a format. I estimated it to be c60ms. The same albums/tracks when encoded with flac did not display this characteristic.

I managed to get Cambridge Audio to admit that it was an audible flaw in .m4a/aac decoding and they have agreed to solve it in a forthcoming firmware release. That was very impressive, I thought.

Meanwhile, I had tracked the problem, via the developer of mpd to a "bug" in ffmpeg, a piece of software which is widely used in audio encoding/decoding. I suspect that CA are one user of ffmpeg. I registered it with ffmpeg as a bug, and recently received a reply which rather surprised me. It turns out that .m4a/aac files created with iTunes are not supported by ffmpeg for gapless processing. Something to do with null samples in the data at the beginning and end of the track, and how to tell the decoder how many there are. iTunes uses a iTunSMPB tag in the metadata to do this and ffmpeg doesn't recognise this tag. More info which I don't understand here.

Since CA have said they will fix the problem, I am not overly concerned, but I would be interested if anyone can recommend a way of converting these iTunes files to something which ffmpeg will play truly gaplessly. Somebody at ffmpeg was very helpful about this, but I couldn't understand the response.
Marmite

Interesting. The nature of lossy compression using mDCT https://en.wikipedia.org/wiki/Modified_d..._transform gives rise to the problem you have found at the beginning of any such compressed audio file - you need something to overlap with.

For aac in m4a files there appear to be 2 solutions: iTunSMPB or a later ISO standard as mentioned in the response you got.

You should be able to figure out whether the ffmpeg code can handle the ISO version of this using qaac, this is a Windows command line program that drives the Apple iTunes encoder software. You can then encode with both versions, see: https://github.com/nu774/qaac/wiki/Encod...figuration

This should enable you to test your mpd installation. If it works with your m4a files that include the ISO gapless information, then you know what to do in future. If it doesn't, then you know what the problem is.

As for converting old files, if ffmpeg doesn't support this, then one other possibility is mp4box from gpac. This project seeks to be standards compliant, so if it doesn't do this, it might accept it as a feature request. see: https://github.com/gpac/gpac

OTOH disk space is cheap, so standardising on flac would also solve your problem. Even though it seems inelegant to use disk space for no audible benefit outside track transition.

Really the problem is tracks. CDs (or even vinyl) don't have tracks, they have cueing points. Most competent PC based music players can read cue sheets, and will handle one audio file and a cue sheet perfectly. Upnp doesn't support this, although playing one file will mean there are no gaps, and you could create separate files where gaps didn't matter

Mike

PS - should we have a capability matrix for renderers? It's very hard to find out what the limitations are, and as Marmite has shown the manafacturers may not know.