Thank you for your donation!


Problem: Gapless issue on lossy formats supported gapless playback
#1
Problems:

Unfortunately, in the case of lossy codecs that officially support gapless playback, we cannot speak of correct gapless playback. A slight click / glitch appears with OGG Vorbis files, and a short (<0.5s) pause for OPUS files. Version 6.6, 6.7.1 with mpd default setting. Despite the assurances of the authors of the mpd project about removing the gapless problem, unfortunately, mpd cannot do it on lossy files. The same files play correctly on Foobar2000 on a PC. (The OGG Vorbis files played using Rockbox 3.15 do not have a gapless problem but there are short gaps in the files with the OPUS codec usage).

The problem with gapless playback is not related to the I2S DAC, because I find the same behavior on the HifiBerry DAC +
My little brick in this device - a tube buffer similar to the diamond topology (double cross coupled balanced path). http://zweimann.pl/product/zweimann-dac-...e-edition/
Reply
#2
(08-13-2020, 09:16 AM)STUDI Wrote: Problems:

Unfortunately, in the case of lossy codecs that officially support gapless playback, we cannot speak of correct gapless playback. A slight click / glitch appears with OGG Vorbis files, and a short (<0.5s) pause for OPUS files. Version 6.6, 6.7.1 with mpd default setting. Despite the assurances of the authors of the mpd project about removing the gapless problem, unfortunately, mpd cannot do it on lossy files. The same files play correctly on Foobar2000 on a PC. (The OGG Vorbis files played using Rockbox 3.15 do not have a gapless problem but there are short gaps in the files with the OPUS codec usage).

The problem with gapless playback is not related to the I2S DAC, because I find the same behavior on the HifiBerry DAC +

If it's a problem with MPD then you need to post your issue to the MPD repo or to the MPD Forum. (Hint: first read some of the existing issues and responses to them to get a feel for the amount of detail you'll be required to present.)

Regards,
Kent
Reply
#3
I'm unable to replicate with my Pi3B+ & Topping D50s DAC.
I've just put on a live album that I happen to have in ogg vorbis, no anomalies or gaps.

Edit: tracked down some random YouTube videos that don't have silence at the beginning/end and downloaded the opus audio feeds using youtube-dl. Can't seem to replicate with opus either.
Reply
#4
Unfortunately the problem is there. It is not as clear as in the absence of gapless and MP3, for example, but unfortunately MPD does not always cope with lossy formats. It doesn't always show up, sometimes a small number of samples are omitted, sometimes we already have several dozen milliseconds. In general, MPD in the case of OGG Vorbis is better at switching between songs, but in the case of OPUS it is much worse. Each of these tiresome cases (statistically about 5% of resources) is played flawlessly in Foobar2000, sticking two files together in an editor such as Sound Forge shows a perfect continuation in the next file. 

I do not rely on "ready" music files. It is always either a rip from a CD or a lossless file merged with a cue file, then there is the separation of the songs in the FLAC rom into individual files and only then the conversion to the OPUS or OGG VORBIS format (modified - aotuv, and I avoid "combines" for conversion audio files because they lose with a simple frontend for CLI converters like Xrecode). 

Yes, I know that OPUS is more modern, more transparent than OGG VORBIS, but unfortunately the player implementations still have bugs. An example where MPD fails completely with both OGG VORBIS (very delicate glitch) and OPUS (even a break) is the re-release of the album Inot The Electric Castle (performer Ayreon), the originally received CUE and the merged file from the entire album, unfortunately after splitting into track files, it shows this problem (most audibly between the first and second track from the first album). The second album is, for example, Oxygene (J.M. Jarre, between the first and second track on more releases this CD  - MPD also fails ...). I do not have time to check whether by moving the track end marker in the merged file with the entire disc you can get the correct playback transition between tracks (once this procedure removed the problem, you had to hit so that the decoder in the player did not insert padding).  

I don't even consider YouTube as a music source for obvious reasons. Just for comparison, which of the re-edition of the album is of good quality, I rely on the files from the CUE sheet with the given rip verification, content evaluation in terms of MPEG compression words and with standard spectrograms.
My little brick in this device - a tube buffer similar to the diamond topology (double cross coupled balanced path). http://zweimann.pl/product/zweimann-dac-...e-edition/
Reply
#5
(08-14-2020, 07:42 AM)STUDI Wrote: MPD does not always cope with lossy formats. It doesn't always show up, sometimes a small number of samples are omitted, sometimes we already have several dozen milliseconds. In general, MPD in the case of OGG Vorbis is better at switching between songs, but in the case of OPUS it is much worse. Each of these tiresome cases (statistically about 5% of resources) is played flawlessly in Foobar2000, sticking two files together in an editor such as Sound Forge shows a perfect continuation in the next file.

This doesn't really make a lot of sense, I'm using the same version of mpd as you are and it's fine with a different DAC.
This smells of the signal being muted by the DAC whilst clock sync is not locked. The tell-tale sign would be that the silence is a mute not a pause. Try testing with the Pi's internal sound device through the 3.5mm jack and see if you still get these gaps.

You can't really compare to Windows in this case as the source PCM isn't being output directly to the DAC in its native sample rate on Windows, thus the DAC is not switching rates regularly because Windows resamples everything to a single, constant sample rate. Desktop operating systems have to do this in order to have multiple programs make noise simultaneously.
On Moode, the bundled programs such as mpd etc. output directly to the ALSA driver, whilst this means only one program can output to the DAC at a time it means the signal is rendered at it's native rate without resampling (unless you choose to enable SoX resampling of course), thus the DAC could be clock resyncing between tracks. Some DACs do this resync transparently, some are slower and output a short burst of noise whilst the clock is unlocked (often called jitter), some mute the noise.

Is this I2S DAC you mention the Zweimann in your link? If so are you using the USB interface?
On the HiFiBerry DAC+ other owners have discussed on this forum and beyond that this DAC suffers from jitter issues, from personal experience I can say the Allo Boss hat has no such problems.
Reply
#6
Quote:This doesn't really make a lot of sense, I'm using the same version of mpd as you are and it's fine with a different DAC.

It has nothing to do with the DAC. It only appears in some specific cases (albums). This seems to be a bug that shows up in specific cases with the end time value of the previous track. I will write about it later.

Quote:This smells of the signal being muted by the DAC whilst clock sync is not locked. (...)

No, there is no closure of the audio stream, i.e. synchronization is continuous. In special cases the software gets lost and inserts padding with "zero" samples.

Quote:You can't really compare to Windows in this case as the source PCM isn't being output directly to the DAC in its native sample rate on Windows, thus the DAC is not switching rates regularly because Windows resamples everything to a single, constant sample rate. Desktop operating systems have to do this in order to have multiple programs make noise simultaneously.

Gapless only affects to the transition between tracks on the same album. So in this situation the previous and the next file use the same handiness and the same sampling rate.

Of course, I know the problem with the multimedia API in Windows, which for digital recording (ADC processing) always requires resolution of 16 bits and sampling not higher than 44.1kHz / 48kHz. By directing the data to an application that requests other sampling parameters, it performs upsampling. I am familiar with this problem as I have been using audio interfaces to measure audio devices. Coenic was the use of ASIO drivers bypassing the multimedia API in Windows. The FFT analysis shows the actual sampling parameters.

Quote:Is this I2S DAC you mention the Zweimann in your link? If so are you using the USB interface?

I am not using the Zweimann DAC. Only for this series of products I have designed the output tube path.


For now, I am not looking into the problem more precisely, because I feel sorry for every sunny warm day. However, I will sit down, take the Focusrite interface out of the drawer and sample what leaves the Moodeaudio-driven DAC in those few cases. At the moment, I only made sure that the problem is not in the lossy files or even FLAC files, but uploading the files to the Sound Forge program confirms that the problem does not lie in the content of the files. My suspicion is more about libraries, external codecs, audio API in relation to MPD. Probably, that at some end times of the song, some software from the environment in which MPD works makes an error and inserts an empty frame (75 ms of silence). This thesis is convinced by the fact that KODI from version 17 for the ARM platform does not support gapless at all, even for lossless files. (a problem known and completely ignored by the authors of this project). Return to PC playback. Foobra allows you to choose to play via standard multimedia API or skip it directly to audio devices via ASIO. In both cases, those problematic for Moode or Rockbox with OPUS file (because OGG Vorbis is OK, i.e. the problem is in codec implementation not in player sotfware) are played correctly.

Unfortunately, currently, in order to have gapless (this is an absolute condition for me to trap a player), I can use Rockbox for OGG Vorbis loss files, Foobar2000 for lossless files supporting gapless, and Moodeaudio only correctly plays lossless files. KODI on the ARM platform is suitable for playing audio only up to version 16 inclusive. None of the newer ones are suitable for playing music.

He adheres to the principle that I am not the one who has to fight with gadget or software. The size of the music billiards owned means that it is practically not possible to adjust it to the specific behavior of the device or software that plays music.
My little brick in this device - a tube buffer similar to the diamond topology (double cross coupled balanced path). http://zweimann.pl/product/zweimann-dac-...e-edition/
Reply
#7
It seems like you've convinced yourself on the cause whilst the rest of us using the same software don't have your problem. As Keith suggested, maybe it'd be better to seek support from the mpd project.
Reply


Forum Jump: