Gaplessness....

[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.