Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Can *any* RaspPi-based streamer handle gapless AAC? (Read 786 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Can *any* RaspPi-based streamer handle gapless AAC?

It appears that streamers based on open-source mpd/ffmpeg code are unable to implement gapless playback of aac files, probably because they aren't correctly handling the metadata tags. I've tested this on the latest builds of both moode and Volumio, and both skip between tracks.

I've uploaded a bunch of test tracks that you can find here:
https://drive.google.com/file/d/1Wr2lHl2Q7NLRDCrt_ErNpinn9xRqjKZs/view?usp=sharing

There are two metadata methods by which gapless aac playback can be implemented, the original Apple scheme using itunsMPB tags, and the ISO method using elst/sdst tags. The files that I've uploaded use two different encoders (qaac and dBPoweramp/FDK), both of which allow the tagging method to be specified ('gm' refers to encoding via qaac using the --gapless-mode option as specified in its docs). No matter which encoder I use or which gapless mode tagging is implemented, they all fail, with an audible tick between tracks because ffmpeg isn't skipping the priming samples.

Looking at mpd's log I see ffmpeg throwing a "ffmpeg/aac: Could not update timestamps for skipped samples" warning, but only when playing the files encoded by qaac. This is thrown at this point in the ffmpeg code. ffprobe seems to show that ffmpeg is recognising both the itunsMPB and ISO tags, so I don't know if this is an ffmpeg issue or because mpd isn't properly setting the pkt_timebase. Since the files encoded with dBPoweramp/FDK don't result in this warning but still skip between tracks I'm not sure of the relevance of this warning.

All these files play with perfect gapless performance in foobar2k, and I never had this problem with Audirvana when I was using a Mac. I've included a set of files encoded with mp3 and ogg, both of which are perfectly gapless on moode (as are flacs of course), so this is just a problem with aac files.

I know there are lots of other music players for the Raspberry Pi, like picoreplayer and RopieeXL, so if you are using one of those I'd really appreciate it if you could test the files I linked above and let me know if your player can handle them gaplessly. This would save me flashing and setting them up.

I posted this over on ASR and someone pointed out that there appear to be several issue tickets on the ffmpeg tracker concerning this, but it seems no-one has addressed the issue, leaving every player that uses ffmpeg broken as far as gapless aac goes. Are there any RaspPi builds that don't rely on ffmpeg?

Re: Can *any* RaspPi-based streamer handle gapless AAC?

Reply #1
I know there are lots of other music players for the Raspberry Pi, like picoreplayer and RopieeXL, so if you are using one of those I'd really appreciate it if you could test the files I linked above and let me know if your player can handle them gaplessly. This would save me flashing and setting them up.
I tried them out on piCorePlayer v7.0.0 - which runs Squeezelite v1.9.8
This was on a RPi2 with HiFiBerry DIGI2 Pro HAT, but my experience is that piCorePlayer runs the same on any Pi. (I've had it running fine on a Pi4B, and even on a Pi1).

The dbPower-FDK-ISO and gm1 versions did NOT play gaplessly.
All the others played gapless.

This was very much a casual test, and I didn't examine in detail what processes were fired up. I don't know what decoding engine Squeezelite uses.

(Surprisingly, trying them out on a Squeezebox Classic, NONE of the M4A files played gapless. I guess the old firmware hasn't kept up).

Re: Can *any* RaspPi-based streamer handle gapless AAC?

Reply #2
(Surprisingly, trying them out on a Squeezebox Classic, NONE of the M4A files played gapless. I guess the old firmware hasn't kept up).
Errata: it was a Squeezebox 2, not a Classic. (It's in the loft, feeding ceiling speakers in the bedrom, and I'd forgotten which one was up there).
But my understanding is that the SB2 and Classic run exactly the same firmware, so not really significant.

Re: Can *any* RaspPi-based streamer handle gapless AAC?

Reply #3
I know there are lots of other music players for the Raspberry Pi, like picoreplayer and RopieeXL, so if you are using one of those I'd really appreciate it if you could test the files I linked above and let me know if your player can handle them gaplessly. This would save me flashing and setting them up.
I tried them out on piCorePlayer v7.0.0 - which runs Squeezelite v1.9.8
This was on a RPi2 with HiFiBerry DIGI2 Pro HAT, but my experience is that piCorePlayer runs the same on any Pi. (I've had it running fine on a Pi4B, and even on a Pi1).

The dbPower-FDK-ISO and gm1 versions did NOT play gaplessly.
All the others played gapless.

This was very much a casual test, and I didn't examine in detail what processes were fired up. I don't know what decoding engine Squeezelite uses.

(Surprisingly, trying them out on a Squeezebox Classic, NONE of the M4A files played gapless. I guess the old firmware hasn't kept up).

Thanks!
Yes, it seems pCP is the way to go, and any player based on mpd/ffmpeg can't handle gapless aac. This is probably true of any LMS/Squeezelite build as long as it doesn't enable ffmpeg (which I see is an option) and instead decodes aac using faad.

I've spent the last couple of days playing around with pCP and found that inserting server-side DSP using the custom_convert.conf file also breaks gapless playback (at least using a simple faad | sox command), probably because of latencies involved. Maybe the failure on the Squeezebox 2 is because LMS is transcoding everything to mp3? The solution for pCP is to do DSP on Squeezelite using camilladsp, which I've finally got working.

Re: Can *any* RaspPi-based streamer handle gapless AAC?

Reply #4
I've spent the last couple of days playing around with pCP and found that inserting server-side DSP using the custom_convert.conf file also breaks gapless playback (at least using a simple faad | sox command), probably because of latencies involved.
I use a custom-convert.conf file for DSP and don't have any problem with gapless. All my library is FLAC, so the conversion involves decoding with FLAC then piping into SOX. Watching the processes, LMS clearly starts up the next transcode a few seconds before it's due to play. I have no experience with FAAD.

What output format are you creating from the SOX output? I get it to re-encode to FLAC level 0.
Maybe the failure on the Squeezebox 2 is because LMS is transcoding everything to mp3? The solution for pCP is to do DSP on Squeezelite using camilladsp, which I've finally got working.
I just tried it again and kept an eye on the LMS processes, and as far as I could see there was no transcoding.

 

Re: Can *any* RaspPi-based streamer handle gapless AAC?

Reply #5
I've spent the last couple of days playing around with pCP and found that inserting server-side DSP using the custom_convert.conf file also breaks gapless playback (at least using a simple faad | sox command), probably because of latencies involved.
I use a custom-convert.conf file for DSP and don't have any problem with gapless. All my library is FLAC, so the conversion involves decoding with FLAC then piping into SOX. Watching the processes, LMS clearly starts up the next transcode a few seconds before it's due to play. I have no experience with FAAD.

What output format are you creating from the SOX output? I get it to re-encode to FLAC level 0.

Maybe I should try it again, though CamillaDSP seems fine right now. I was outputting flac from Sox, but I don't think I explicitly set the compression level so it might have been slowing down a bit by compressing too much.