I have made the test
- Default location of database
- Connect to DAC with Ethernet/CPL
- Plugin Apple AUGraphiqEQ
It is OK.
I did not think that setting the database on an external SSD disk could cause an issue.
Very interesting. I have the issue of prematurely ending tracks too, some (most?) of the time. I will take notes next time it happens and pay attention to the source (local SSD vs SMB share), the file format and processing settings. My setup is quite straight forward – Mac mini connected to D50 DAC via USB.
Since the database is on the internal Fusion Drive, i have no problem, although i have an ethernet/cpl connection with my DAC.
It seems that my issue was due to the the access to the database while processing the end of track, when the access to the database is not fast enough.
I have seen this problem with many tracks, but I have selected a track for which I can reliably reproduce the chopped off ending. It happens to be the last track of an album, which seems to be where this bug occurs most often.
First of all, it reliably happens to this track when forced upsampling (power of 2) is enabled. It reliably does not happen when forced upsampling is disabled. The track is a 16/44.1 FLAC file ripped from a CD. With upsampling, what’s being sent to the DAC (Topping D50s) via USB is 32/705.6.
This particular track goes for 4:08, but with upsampling enabled it stops after 3:59. This apparently has to do with time keeping and the progress bar. The following screenshots show the progress bar at various stages during playback.
After starting playback, a white progress bar quickly runs across, but (unlike with no upsampling) a bit of it remains at the end:
As the track plays on, the actual (light blue) progress bar gets longer. The played and remaining time adds up to 4:08:
As the progress bar approaches the white bit the two times still add up to 4:08:
When the progress bar reaches the white bit the weirdness begins. The white bit disappears and a new, lighter blue, progress bar now starts where the white bit used to start. The played and remaining times no longer add up to 4:08, but to 3:59:
As the track goes on, the new progress bar starts filling the space previously occupied by the white bit, the two times still add up to 3:59:
As the track nears its end, the times still add up to 3:59:
When the remaining time counter reaches -0:00, playback stops, 9 seconds before the actual end of the track.
When forced upsampling is disabled, there is no remaining white bit (after the initial quick white progress bar), and the two counters add up to 4:08 at any point during playback.
I checked the actual playback times with and without upsampling using a stop watch, they are indeed 3:59 and 4:08, i.e. playback isn’t slowed down or sped up.
I’ve got debug info dumps with and without upsampling, if that’s of any help.
I hope this bug can be put to rest soon, because it’s driving me nuts. For now, I’ll play without forced upsampling.
After re-reading the very first post in this thread, I want to point out that in my case (as above) I’m never getting any errors or messages about corrupt tracks. Playback simply stops prematurely.
Perhaps my situation is different from csalome’s, and more akin to this thread: Bug report: end of track is cut off, does not play to end
I have the same problem – though all my track are on the internal SSD. Any suggestions?
See details & log in my post here: Bug report: end of track is cut off, does not play to end
I have sometimes this problem,but only on the first track of a playback.
After a first stop, if i play again, all tracks follow normally.
All my tracks are on an external hard disk, and as said previously, i got a great improvement while moving the database from an external hard disk to the internal hard disk.
My computer is an iMac 27, and during playback, cpu load does not exceed 5%.
This topic was automatically closed 375 days after the last reply. New replies are no longer allowed.