Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[carl99]

When I rip a CD into MC and then convert it to DSD using this application, I end up with a great rip....EXCEPT that between each track, there is an annoying "pop" which is slight during headphone usage, but really loud and annoying when played over speakers.
Can this be eliminated??

[JimH]

The pop is probably coming from your DAC.  Try converting to something lower, as a test.

[Awesome Donkey]

Are you using. dsf? Try .dff if you are.

[carl99]

The pop is probably coming from your DAC.  Try converting to something lower, as a test.

Thank you, but in playback of theses rips, I use different DACs, including and Astell & Kern AK 240 and a PS Audio Directsream.
BTW, I found an earlier thread here which attributed a like problem to a failure to handle the data in the tags properly and recommended setting this program "...to always convert/ L16 no header..."
Can you translate, please?

[carl99]

Are you using. dsf? Try .dff if you are.

I am a newbie. How do I do that?
Plus, please see my last reply. Does that make any sense as a possible solution?

[Awesome Donkey]

MC uses sacd_extract, correct? If so, there's a possible bug when encoding an ISO to DSF files that could create these "pops". However, if you encode to DFF the pop isn't present but there's no metadata support for DFF. The *only* workaround I found for this is to first encode the source to DFF files then on the Mac run dff2dsf and create new DSF files. Those DSF files don't suffer from this bug.

I encountered this issue with my SACD ISO rip of Pink Floyd's Wish You Were Here. I ended up having to output individual stereo tracks to .dff then using dff2dsf on the Mac to create perfect .dsf files without this issue - gapless playback is perfect.

[JimH]

MC uses sacd_extract, correct?

I don't think we use it.

[Awesome Donkey]

Hmmm, nonetheless it should be pretty easy to reproduce. Take an SACD ISO, Pink Floyd's Wish You Were Here is perfect for this, and convert the tracks to .dff and .dsf - I've used both JRiver and sacd_extract to convert to single tracks from the ISO as a comparison. Just listen to the last minute of Have A Cigar as the track changes to Wish You Were Here (which should be a gapless transition) - the .dff files should be gapless (and perfect) with no audible 'pop'/distortion whereas the .dsf may and probably will exhibit a noticeable 'pop'/distortion as the track changes from Have A Cigar to Wish You Were Here. The transition from Wish You Were Here to Shine On You Crazy Diamond (Parts VI-IX) is another good example to test.

This issue is also referenced in this topic.

[carl99]

Hmmm, nonetheless it should be pretty easy to reproduce. Take an SACD ISO, Pink Floyd's Wish You Were Here is perfect for this, and convert the tracks to .dff and .dsf - I've used both JRiver and sacd_extract to convert to single tracks from the ISO as a comparison. Just listen to the last minute of Have A Cigar as the track changes to Wish You Were Here (which should be a gapless transition) - the .dff files should be gapless (and perfect) with no audible 'pop'/distortion whereas the .dsf may and probably will exhibit a noticeable 'pop'/distortion as the track changes from Have A Cigar to Wish You Were Here. The transition from Wish You Were Here to Shine On You Crazy Diamond (Parts VI-IX) is another good example to test.

This issue is also referenced in this topic.

Sorry, but I am a newbie: how do you convert to diff??

[Awesome Donkey]

Well, what is your source DSD file(s)? ISO?

[carl99]

Well, what is your source DSD file(s)? ISO?

Sorry to be such a drag, but I don't know from ISO. The process that I use is ripping a CD to MC, then using the conversion option to convert to DSD...so, what do I do now??

[blgentry]

^ Why would you try to convert something from a CD to DSD anyway?  CDs are PCM, which is sort of the polar opposite of DSD.  Not literally, but from a digital audio technology standpoint they are completely different.

Why not just play ripped CDs in the file format you rip them to?  FLAC, AIFF, APE, etc are what you should be using for CDs.

Just MHO.

Brian.

[Y. G. Bae]

Hello Carl,

Brian is correct. Redbook CDs are encoded in 16bit 44.1kHz PCM, and there is no way to change it, and you don't gain anything by upconverting it because all of the other information was already lost when it was encoded (or even when the music was recorded/mastered), and you are just increasing the container for no other content to fill up. I wouldn't even use DSD for PCM because you are introducing noise to perfectly clean high frequency range. Going for better recorded sources will let you enjoy listening more.

Best regards,
Y. G.

[digimuse]

Like the original poster, I am finding that there are loud pops in between .dsf tracks. I am running MC20.0.126 on a Mac mini running OS X 10.10.4, with music on a local disk drive, and connecting to my DAC over the LAN.

The problem does not occur on all .dsf albums, but some. For example, I have found it on about a third of the tracks of Vivaldi: L'Estro Armonico. I bought this from nativedsd.com, and it is a Channel Classics recording. I got the 64fs DSD version, and all the tracks are in .dsf format.

I have tried MC20 on different Mac computers, but the pops remain with the problematic tracks. I have tried connecting the Mac to the DAC directly via Ethernet, and connecting the Mac and DAC to via a shared switch, but the pops remain.

I have found no problems when playing the problematic tracks:

 - using MC20 with a USB interface to the DAC, nor when
 - using the MinimServer on the same mac (which connects to the DAC over the LAN)

Converting to .dff, losing all the metadata, and then reentering this is not a task I relish.

I don't see any indication that this problem has been solved.

Are there any plans to look into this?

I really like MC - I've been using MC18, MC19, and MC20, and I have already preordered MC21. But if these pops don't go away MC will not be an option for me.

Thank you,

Narinder

PS: I think one of these pops blew the midrange in one of my speakers. They can be loud!

[Matt]

Could you throw a sample of two tracks that pop on switching to matt at jriver dot com?

Also is the pop only when bitstreaming or only when playing as PCM?

Thanks.

[digimuse]

Thanks Matt - I just sent you an email with some problematic .dsf tracks.

I have only heard the pops when playing .dsf files - I haven't noticed any pops with PCM (44.1, 88, 96, 176, or 192 kHz). I do not have any .dff music files.

[Matt]

Thanks Matt - I just sent you an email with some problematic .dsf tracks.

Thanks.  Please keep the files up until Monday and I'll pull them then.

I have only heard the pops when playing .dsf files - I haven't noticed any pops with PCM (44.1, 88, 96, 176, or 192 kHz). I do not have any .dff music files.

I mean are you playing as a bitstreamed DSD signal or a PCM signal?  In other words, do you have Options > Audio > Bitstreaming set to DSD or to none?  And what happens if you switch?

[digimuse]

Sorry for the confusion:

When playing a problematic .dsf file I do hear a pop at the transition to the next song when:
  -  Options -> Media Network -> Add or configure DLNA servers... -> Advanced -> Bitstream DSD (requires DOPE compliant
      renderer) <CHECK>
  - with this configuration, the DAC indicates that DSD data is being received

When playing a problematic .dsf file I do not hear a pop at the transition to the next song when:
 - Options -> Media Network -> Add or configure DLNA servers... -> Advanced -> Bitstream DSD (requires DOPE compliant
    renderer) <UNCHECK>
 - with this configuration, the DAC indicates that 24 bit/176.4 kHz data is being received

[Matt]

Well I'm not having much luck.  I downloaded 03 and 04.

I'm playing them to a Mytek Digital DAC and bitstreaming the DSD.

The transition is perfect.

I also tried disabling bitstreaming so MC is delivering PCM.  That's perfect too.

I wonder if you using DLNA could be part of the problem?  Would you be willing to hook your DAC up directly to test that theory?

[digimuse]

That's good to know that you aren't having any pops while playing the same .dsf files that give me trouble.

Were you using the DLNA (network) connection for this test?

If you hear the pops via DLNA, it will be a relief that its most likely a problem with MC20 and not my DAC.

But if you do not hear pops via DLNA, it points to a possible incompatibility with my DAC, or a problem with my DAC. I am hoping to try out another identical DAC in a couple of weeks to see if the pops remain.

To answer your questions:

When connecting my Mac mini running MC20 to my DAC via USB, and using the "Player" renderer:

I have no pops streaming .dsf directly:
 - Options -> Audio -> Settings -> Bitstreaming: "Yes (DSD)"
 - with this configuration, the DAC indicates that DSD data is being received

I also have no pops when converting the .dsf files to PCM:
 - Options -> Audio -> Settings -> Bitstreaming: "None (recommended)"
 - with this configuration, the DAC indicates that 24 bit/176.4 kHz data is being received

So, yes, I only have problems streaming some .dsf files directly via DLNA.

As a side note, connecting to a DAC via USB has some features that are missing with a DLNA connection. For example:
 - Options -> Audio -> Audio Device -> ... Device Settings ... -> Buffering -> [great to be able to add similar buffering with
    DLNA?]
 - Options -> Audio -> Settings -> Play files from memory instead of disk (not zone-specific) <CHECK> [help with DLNA?]

Not sure if having these features would help with my DLNA problems.

Also unrelated to my problem:

For DLNA:
 - Options -> Media Network -> DSP Studio -> ... Add or configure DLNA servers ... -> Audio -> Advanced -> ... DSP Studio .. ->
   Output Format

changing "Output Encoding" doesn't seem to do anything (e.g., to convert everything to DSD)

 And changing "Sample rate (more info)" doesn't do anything. You have to use the simpler:
 - Options -> Media Network -> ... Add or configure DLNA servers ... -> Advanced -> Sample rate:
   <set to one fixed output sample rate for all input sample rates - DSD is not an option>

[Matt]

So, yes, I only have problems streaming some .dsf files directly via DLNA.

That's interesting.

I've asked our resident DLNA expert to take a look.

[bob]

That's good to know that you aren't having any pops while playing the same .dsf files that give me trouble.

Were you using the DLNA (network) connection for this test?

If you hear the pops via DLNA, it will be a relief that its most likely a problem with MC20 and not my DAC.

But if you do not hear pops via DLNA, it points to a possible incompatibility with my DAC, or a problem with my DAC. I am hoping to try out another identical DAC in a couple of weeks to see if the pops remain.

To answer your questions:

When connecting my Mac mini running MC20 to my DAC via USB, and using the "Player" renderer:

I have no pops streaming .dsf directly:
 - Options -> Audio -> Settings -> Bitstreaming: "Yes (DSD)"
 - with this configuration, the DAC indicates that DSD data is being received

I also have no pops when converting the .dsf files to PCM:
 - Options -> Audio -> Settings -> Bitstreaming: "None (recommended)"
 - with this configuration, the DAC indicates that 24 bit/176.4 kHz data is being received

So, yes, I only have problems streaming some .dsf files directly via DLNA.

As a side note, connecting to a DAC via USB has some features that are missing with a DLNA connection. For example:
 - Options -> Audio -> Audio Device -> ... Device Settings ... -> Buffering -> [great to be able to add similar buffering with
    DLNA?]
 - Options -> Audio -> Settings -> Play files from memory instead of disk (not zone-specific) <CHECK> [help with DLNA?]

Not sure if having these features would help with my DLNA problems.

Also unrelated to my problem:

For DLNA:
 - Options -> Media Network -> DSP Studio -> ... Add or configure DLNA servers ... -> Audio -> Advanced -> ... DSP Studio .. ->
   Output Format

changing "Output Encoding" doesn't seem to do anything (e.g., to convert everything to DSD)

 And changing "Sample rate (more info)" doesn't do anything. You have to use the simpler:
 - Options -> Media Network -> ... Add or configure DLNA servers ... -> Advanced -> Sample rate:
   <set to one fixed output sample rate for all input sample rates - DSD is not an option>

Sending tracks via TCP/IP (DLNA) is a lot different than via directly connected hardware.
The buffering is controlled by the renderer (the DAC), how much data it requests at a time.
It's possible you are getting underruns on the data which could be from the PC sending the data or because of LAN issues.

A few questions.
1) Is this completely repeatable (you get the pops in exactly the same place every time)?
2) What is the format of a source track (container, sample rate, etc).
3) What is your network configuration?

[digimuse]

1) Is this completely repeatable (you get the pops in exactly the same place every time)?

On the .dsf tracks that cause a pop at the transition to the next track, I'd say the pop happens every time. It's possible that there was an occasion that it did not, and I missed that

2) What is the format of a source track (container, sample rate, etc).

The problematic music files are DSD64 in a .dsf container (1 bit, 2.8224 MHz).

You can examine some of the problematic files - I emailed Matt a link, and I do the same for you, if you let me know your email address. These are from ChannelClassics.com:
https://channelclassics.nativedsd.com/albums/lestro-armonico

3) What is your network configuration?


Mac Mini ----(Cat 7 Ethernet)----> Wireless Bridge <----(Cat 7 Ethernet)---- DAC

Mac Mini: running JRiver MC 20.0.126 acting as Server and Control Point, with all music files stored locally on a separate internal hard drive

 - Mac mini (Mid 2011)
 - OS X Yosemite 10.10.4
 - 2.5 GHz Intel Core i5
 - 8 GB 1333 MHz DDR3
 - Macintosh HD: OCZ Vertex 3, 256 GB (SSD) [internal to Mac mini]
 - Music HD: Western Digital SATA III 5400 RPM 8 MB Cache, 1TB [internal to Mac mini]

The Mac mini:

 - wireless is turned off (the wireless bridge provides Internet connection)
 - no other user application is used when playing music
 - when playing music (e.g., when a pop occurs)
     the processor is around 96% idle
     memory: used 2.43 GB, Cache 5.19 GB, Swap Used: 0 bytes [from Activity Monitor]

Wireless Bridge; Linksys WUMC710 (has four Gigabit Ethernet ports -- Mac mini and DAC plug into this). Provides Internet connection.

I do not get any pops when running MinimServer and using PlugPlayer as the Control Point - both running on the Mac mini . This would indicate that it is possible to play the problematic tracks without pops.

[when running MinimServer and MC20 as the Control Point on the Mac mini - playback stops after each song - a different problem]

Just tried out the same music file MC19.0.163 - and got the same pops

Also, as I had mentioned earlier, I do not get the pops with MC20 as the Server and Control Point on the Mac mini - when using a USB connection from the Mac mini to the DAC.

[Wybe]

I have almost the same setup and also experiencing pops on sacd iso, dff and dsf files. Like digimuse already states the pops are gone, when unchecking Bitstreaming in the Network configuration (DLNA/UPNP). However, the DAC now indicates that PCM files are played. When checking Bitstreaming the DAC indicates that DSD files are being played, but now I hear minor pops at the start and end of the song. I will be following this thread with great interest ...

[digimuse]

I wanted to report on some further tests. These are with the same DLNA (Ethernet) connections to the Renderer/DAC.

I was able to try out a different, but identical, DAC - but the pops remain with the new DAC when using JRiver MC20 on a Mac (Server and Control Point). So it's less likely that my DAC has a problem (though both DACs could have a shared problem).

I tested the problematic tracks with JRiver MC20 running on a Windows PC (Server and Control Point), and there were no pops. This would support that there is something wrong with the Mac version of JRiver MC20.

When using JRiver MC20 on a Mac (both Server and Control Point), and converting the problematic .dsf tracks to .dsf (using the JRiver Convert Format utility), the pops remain. The goal of this test was only to see if the conversion would remove pops (possibly fixing bad metadata).

[converting from .dsf to .dsf in JRiver may go through a PCM conversion which is suboptimal, e.g., ANALYSIS: A Comparison of DSD Encoders & Decoders (KORG AudioGate, JRiver MC, Weiss Saracon)]

When using JRiver MC20 on a Mac (Server and Control Point), and trimming the ends of the tracks with transitions that generate pops - the pops were eliminated. The trim process involved Edit -> Tag; click on settings icon to select "Show All Tags", and then edit the tag "Playback Range". I removed a few seconds from the end of the track.

Lastly I wanted to see if there could be a problem with the music files themselves. I converted the problematic tracks to FLAC using JRiver's conversion tool. The .dsf files were converted to 24 bit/352.8 kHz FLAC files. I examined these FLAC files in Audacity and found NO anomalies at the start/end of tracks - no pops, clicks, step functions, impulse functions. It could also be that there are problems in the .dsf file start/ends that are "fixed" by the JRiver .dsf to FLAC conversions. A more definitive test would require looking at the .dsf files using a tool like the Weiss Saracon-DSD. Also, perhaps there is meta-data in the files that is causing pops.

[digimuse]

I ran few more tests, which point to an anomaly in the behavior of JRiver MC20 on a PC.

In these tests I had a DLNA connection from JRiver to my DAC, and I was playing .dsf tracks from Vivaldi: L'Estro Armonico

JRiver MC 20.0.131 running on Windows 7 Professional (Server and Control Point):

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) CHECK
 -  tracks shown as DSD on the DAC
 - pops between tracks (so the pops can show up on the PC version of JRiver - not just the Mac version)

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) UNCHECK
 - tracks shown as DSD on the DAC -- THEY SHOULD NOT - WE TURNED OFF BITSTREAM!
 - NO pops between tracks - Why do the pops go away when Bitstream is turned off?

It looks like JRiver MC20 on Windows is sending DSD even when Bitstream is turned off!  What's even more weird, is that there are no pops at track transitions in this case.


JRiver MC 20.0.126 running on OS X Yosemite 10.10.4 (Server and Control Point):

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) CHECK
 - tracks shown as DSD on the DAC
 - you hear a pop between tracks

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) UNCHECK
 - tracks shown as 24/176.4 on the DAC
 - NO pops between tracks

JRiver MC 20 on a Mac seems like it is doing the right thing - send DSD when you check Bitstream and sends PCM when you uncheck Bitstream. Unfortunately, when it sends DSD, there are pops between tracks.

From my earlier tests, there were no pops when I trimmed a few seconds from the tail of the tracks. Perhaps there is some bad data at the end of a track that is causing the DAC to hard mute (causing a pop). There are no pops when playing a single track - only at track transitions when playing multiple tracks - could JRiver MC20 filter bad data at the tail when there is no more music to play?

Also, not sure why there are no pops at track transitions for the Windows version of JRiver when Bitstream is unchecked (and it actually sends DSD).

[bob]

I ran few more tests, which point to an anomaly in the behavior of JRiver MC20 on a PC.

In these tests I had a DLNA connection from JRiver to my DAC, and I was playing .dsf tracks from Vivaldi: L'Estro Armonico

JRiver MC 20.0.131 running on Windows 7 Professional (Server and Control Point):

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) CHECK
 -  tracks shown as DSD on the DAC
 - pops between tracks (so the pops can show up on the PC version of JRiver - not just the Mac version)

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) UNCHECK
 - tracks shown as DSD on the DAC -- THEY SHOULD NOT - WE TURNED OFF BITSTREAM!
 - NO pops between tracks - Why do the pops go away when Bitstream is turned off?

It looks like JRiver MC20 on Windows is sending DSD even when Bitstream is turned off!  What's even more weird, is that there are no pops at track transitions in this case.


JRiver MC 20.0.126 running on OS X Yosemite 10.10.4 (Server and Control Point):

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) CHECK
 - tracks shown as DSD on the DAC
 - you hear a pop between tracks

Options -> Media Network -> Add or Configure DLNA Servers -> Advanced -> Bitstream DSD (requires DOPE ...) UNCHECK
 - tracks shown as 24/176.4 on the DAC
 - NO pops between tracks

JRiver MC 20 on a Mac seems like it is doing the right thing - send DSD when you check Bitstream and sends PCM when you uncheck Bitstream. Unfortunately, when it sends DSD, there are pops between tracks.

From my earlier tests, there were no pops when I trimmed a few seconds from the tail of the tracks. Perhaps there is some bad data at the end of a track that is causing the DAC to hard mute (causing a pop). There are no pops when playing a single track - only at track transitions when playing multiple tracks - could JRiver MC20 filter bad data at the tail when there is no more music to play?

Also, not sure why there are no pops at track transitions for the Windows version of JRiver when Bitstream is unchecked (and it actually sends DSD).

Is the audio format setting in DLNA the same in the windows and mac builds (in this case they both should be "original format")

[digimuse]

Is the audio format setting in DLNA the same in the windows and mac builds (in this case they both should be "original format")?

No, the Mac version had: Options -> Media Center -> Add or configure DLNA servers ... -> Audio
 - Mode set to "Specified output format"
 - Advanced
   - Sample Rate set to "Same as source"
   - DSP Studio... disabled

When I changed the Mode to "Original", the behavior of the Mac version of MC20 was identical to the PC version of MC20.

That's good, as I can now use the Mac version of MC20 to play .dsf files without any pops by making sure that:
 - Options -> Media Center -> Add or configure DLNA servers... -> Advanced -> Bitstream DSD (requires DoPE compliant renderer) is UNCHECKED

If "Bitstream DSD ..." is checked, I get pops when playing the problematic .dsf files.

It's odd that in order to play .dsf files without pops I have to uncheck "Bitstream DSD (requires DoPE compliant renderer)" for a DAC that supports DoPE.

Also, I thought (incorrectly) that "Specified output format" with Sample Rate "Same as source" and DSP Studio disabled would be the same as Mode set to "Original"

[bob]

Is the audio format setting in DLNA the same in the windows and mac builds (in this case they both should be "original format")?

No, the Mac version had: Options -> Media Center -> Add or configure DLNA servers ... -> Audio
 - Mode set to "Specified output format"
 - Advanced
   - Sample Rate set to "Same as source"
   - DSP Studio... disabled

When I changed the Mode to "Original", the behavior of the Mac version of MC20 was identical to the PC version of MC20.

That's good, as I can now use the Mac version of MC20 to play .dsf files without any pops by making sure that:
 - Options -> Media Center -> Add or configure DLNA servers... -> Advanced -> Bitstream DSD (requires DoPE compliant renderer) is UNCHECKED

If "Bitstream DSD ..." is checked, I get pops when playing the problematic .dsf files.

It's odd that in order to play .dsf files without pops I have to uncheck "Bitstream DSD (requires DoPE compliant renderer)" for a DAC that supports DoPE.

Also, I thought (incorrectly) that "Specified output format" with Sample Rate "Same as source" and DSP Studio disabled would be the same as Mode set to "Original"

If you don't check the "Bitstream DSD" option you are sending the file as-is to your device. If it can play the dsf file that way that's good.
When the "Bitstream DSD" option is on, the dsd is wrapped as a DoPE encoded PCM file. I'm not sure why that would give you pops. Perhaps it a bandwidth issue.

[digimuse]

Thanks for clarifying what the "Bitstream DSD" option does. I wish there was a similar cheat sheet for the semantics of other configuration options.

I don't think the problem is related to bandwidth, as the same behavior is observed when I connect the Mac running JRiver MC20  directly to the DAC with a Cat 7 cable (the Mac is sharing its Internet connection from wireless to the Ethernet port connected to the DAC). There is nothing between the Mac and the DAC on this gigabit cable. So ~3 mega-bits/second for DSD should not be an issue. Also the Mac is not running any other program, all music is stored locally on the Mac, it's 96% idle, and it is not swapping.

If not bandwidth, then maybe the problem is with the DAC or JRiver MC20 not following the same DoPE encoded PCM protocol, or a bug in the DAC or JRiver MC20 for this protocol. Not something I can debug.

But I'm glad that I have a working option with "Bitstream DSD" disabled.

[Wybe]

I suppose you have a DAC that supports native DSD, so there is no need to use the DoPE option. I own a PS Audio DirectStream DAC and this DAC does not support native DSD when using the Bridge. I already hear (minor) pops at the end and start of most of the songs when playing from an SACD iso. Any more suggestions?

[bob]

I suppose you have a DAC that supports native DSD, so there is no need to use the DoPE option. I own a PS Audio DirectStream DAC and this DAC does not support native DSD when using the Bridge. I already hear (minor) pops at the end and start of most of the songs when playing from an SACD iso. Any more suggestions?

You might want to check the next build to see if there is any change.

[Wybe]

Both on my Linux system (MC 21.0.7) and my Mac mini system (MC 20.0.126) I still hear minor pops when playing DSD (iso and dsf). I will try the Mac version 21.0.8 later ...

[Wybe]

I waited a long time for Bridge II in my PS Audio DirectStream DAC. I received it a couple of weeks ago and now enjoying gapless playback via the network! I also updated to the latest JRiver versions of Mac and Linux. Still, no changes with regard to the pop at the start and the end of a DSF file. PCM playback is perfect, but when I play an ISO or a DSF file I hear a minor pop at the start and end of each song. However, sequential album tracks play without a pop between the tracks. Any suggestions?

[bob]

I waited a long time for Bridge II in my PS Audio DirectStream DAC. I received it a couple of weeks ago and now enjoying gapless playback via the network! I also updated to the latest JRiver versions of Mac and Linux. Still, no changes with regard to the pop at the start and the end of a DSF file. PCM playback is perfect, but when I play an ISO or a DSF file I hear a minor pop at the start and end of each song. However, sequential album tracks play without a pop between the tracks. Any suggestions?

That almost sounds like it's on device open since it only happens at the beginning. That might be a driver bug.

[Wybe]

It also occurs at the end of a track. In JRiver I selected in the media network settings "Bitstream DSD (requires DoPE compliant renderer)". What driver are you referring to?

[bob]

It also occurs at the end of a track. In JRiver I selected in the media network settings "Bitstream DSD (requires DoPE compliant renderer)". What driver are you referring to?

My mistake, I forgot you were using DLNA.

[fritsveer]

Hi All,

Have the same issue so found this topic. I have been playing around with the setting as suggested above
using: Naim Superuniti (DSD64-capable), MC20, DLNA,  Macmini.
Playing DSD-iso, .dsf, .dff

I just bought some .dsf albums which after every song have this loud "pop" sound. The "pop"  is only heard on these new .dsf files!

I also have acquired various albums in .iso format and .dff which do not "pop" between songs.

 when:
 - Options -> Media Center -> Add or configure DLNA servers. (original format).. -> Advanced -> Bitstream DSD (requires DoPE compliant renderer) is UNCHECKED
Not be able to play DSD-iso!
most .dff and .dsf play, No "pop"

when:
 - Options -> Media Center -> Add or configure DLNA servers. (original format).. -> Advanced -> Bitstream DSD (requires DoPE compliant renderer) is CHECKED
All files playable
these particular .dsf albums play this loud "pop". On other albums no "pop".

Since i have a substancial amount of dsd-iso i would like to keep the bitstream checked;
Is there a way to play the ISO with Bitstream UNCHECKED
or
Get ride of the "pop"  when playing these .dsf?

nb: the Superuniti recognizes the files as DSD: either on display: WAV 2.8 MHZ, or DSD64

[fritsveer]

NB: found an interim solution for me:
I used XLD to remake .dsf files. These new files do not have the irritating "pop".

[bob]

NB: found an interim solution for me:
I used XLD to remake .dsf files. These new files do not have the irritating "pop".

Where did you get these albums from? I wonder if they are tagged somehow and the pop is the tag?

[fritsveer]

Hi Bob

This is one of the albums I bought:

https://turtlerecords.nativedsd.com/albums/TR0011-jotters-whiffle

If required i may be able to sent some samples.

[bob]

Hi Bob

This is one of the albums I bought:

https://turtlerecords.nativedsd.com/albums/TR0011-jotters-whiffle

If required i may be able to sent some samples.

I know they are huge but perhaps there is a way to chop a bit off of the beginning?

[fritsveer]

Hi Bob
Sent U a PM

[a1bert]

I have been writing a .dsf reader/player and it sounds like a mistake on the part of the generator of the dsf file.

DSD data is stored as 4096-byte blocks (per channel) in the .dsf file, thus the last block needs to be 0-padded.

There is a perfectly good field "number of samples" to hold the number of actual DSD samples in the dsf format, but at least the files I have seen this far put the useless padded length of the data there instead of the correct value. The chunk size gives the size of the data itself, so there is really no reason other than stupidity oversight / programming error to not put the correct number of samples to the number of samples field (fmt chunk).

So, now I'm one of the people who needs to fix this error in the player.

-Pasi
(Also, choosing a padding of 0x55 would've been much wiser from the group that defined the dsf format. But that's not a fault of the people making converters or rippers.)

[fritsveer]

Hi Pasi,

the "DSD data is stored as 4096-byte blocks (per channel) in the .dsf file, thus the last block needs to be 0-padded"
is a bit above my knowledge of the software.

Do I conclude correctly: the JRiver software needs to be updated to eliminate the "pop"?

If you are the right person the have the answer: Do i then in due time upgrade to version 21 or will this ben done for version 20 as well?

[Matt]

Could one of you provide a sample DSF file that clicks at the end to matt at jriver dot com?

I would love to see a sample.

It's totally possible we're overreading, but I just have never seen (or heard) the problem.

Thanks.

[Matt]

Thanks for the sample.

However, all I really have to offer is confusion.

Here's a rundown on that file:
The size of the data block in that file is:
168607756

Then we back out the size of the data structure header, so:
-sizeof(Data)

For a total of:
168607756 - 12
168607744

And that is padded by 4096.

It sure looks to me like we're enforcing the size of 168607744 right.

So what could be going wrong?