When using the TIDAL app I am getting some noise during the first second or two of an MQA song. This appears to be related to switching into MQA mode - for example when the previous song was 16/44.1.
Setup is N6ii with E01 module.
This happens if your playlist contains both MQA and non-MQA songs. It only happens when switching into MQA mode.
Does anyone else experience this?
I just conducted some tests wrt the "noise at PCM/MQA or vice versa switching" issue. In summary, I got the noise in a very few but not all instances, and - honestly - it was not overly distracting for me.
Setup: N6ii with E02 -> balanced into Beyerdynamic Xelento, listening at my usual 32HdB and up to 40 or more HdB
Players: Original Tidal Android App, and Tidal integrated within UAPP
Created two playlists: Each one is alternating CD and MQA quality tracks a couple of times; one playlist with streaming only, one with offlined contents only. (Admittedly, one could think of a playlist that also alternates between streaming and offlined.)
In the original Tidal App, I did get this noise when switching from 16/44.1 to MQA, actually in the offline playlist. A fraction of a second (<0.5 sec) of something that sounds like mild static, low in volume. But with the streaming playlist in the Tidal App and with both playlists in UAPP, the disturbances were hardly noticeable.
I must say that all those little clicks and mutings at track/quality switchovers are much more noticeable than that noise ("white" or "static"). I suspect that with the E02 the mutings might be long enough to cover that noise; in fact, the mutings are long enough to cover the first actual sounds at a track's beginning.
Remark 1: When trying to find out whether these noises occur in Tidal streaming or offlining, I guess one should keep in mind that a streamed track gets cached while being played for the very first time (at least that's what I think to happen), and thus it will be similar to an offlined track at replays thereafter.
Remark 2: Using Tidal within UAPP brought up a lot of weird issues, UAPP stalled and even crashed on me quite often. It seems the app doesn't like to do fast forwards and other actions with the slider bar when streaming, i.e. buffering new contents and picking up at the desired position again. In this test, I wanted to listen to the first few seconds of a track and then slide forward to its last seconds.
Remark 3: Actually, I am not at all the Playlist type of person, I am the Play-an-entire-album person. So I would never have noticed this noise issue... Similar to me noticing the mute at a track's beginning only after quite some time with the N6ii. [In former days, I even had some OCD with music I cherish - I wouldn't stop a track without a manual slow fade-out, and I would listen to all four sides of a 2-LP album in a row... - getting sidetracked.]
I was very worried when I read Taz777's initial complaint, I created a folder to test non-MQA to MQA transition with A02 and T01, I heard faint noise in the first half second, which is not as bad as I anticipated. Noise extended into first two seconds of a song will be really disturbing. Then I bring the follow up messages to our Engineer and go through the problem together.
I have to admit, N6ii is in a less ideal situation when we need to deal with this kind of timing-related problem.
In a normal standalone DAP, the common solution to solve similar problem is to set the idle time between tracks long enough for the mute relay to function correctly, making sure the noise will die down before we start next track. There is a limit on how long we can extend the idle time between tracks because we can only specify an idle time for all tracks, we can't develop a complicated table to allocate different idle time for different scenario, but at least, this is theoretically feasible.
Unfortunately the modular nature of N6ii has make things a lot more complicated. These type of timing-related problem involve synchronisation of different processing, but the clock sync and associated FPGA instructions are resided in the N6ii main chassis. In other word, we can only specify an idle time for ALL Motherboards and all tracks. So you can imagine the difficulties involve when we need to design a sync-and-mute solution to compensate the noise and pop-distortion among different DAC. Fortunately we are experienced with AK4497 (N8), PCM1792A (N6), and ES9038Pro (CS-100DAC), so the solution we have developed are kind of satisfactory for existing motherboards. Unfortunately we only have limited exposure to MQA when we develop the N6ii core system, and that eventually lead to a less than perfect MQA implementation that Taz777 has identified. We can't go back and revise the idle time setting now because the parameter is hard-coded into the EPROM, and we are reluctant to extend the idle time of subsequent production by 1 or 2 second because this will affect all Motherboards in all playback scenarios.
Stay updated on Cayin at their sponsor profile on Head-Fi.
|