Print

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

[bblue]

Starting with version 183 I can't seem to play DSD x1 any more.  You hear about 1/2 second of the song, and about the same of digital hash, then nothing.  MC is set to bitstream DSD, and my DAC (Grace Designs M905) says it's receiving DSD.

What's especially strange is that when I press stop on the song I get an MC dialog box saying:

"One or more UAD Powered Plug-ins have been disabled.
The requestd sample rate 352800 is not supported (-31).
The suported sample rates are 44.1, 48, 88.2, 96 and 192khz."

I do have some UAD powered VST plugins in the DSP chain, but after this message they all show active (still checked).  But with bitstreaming enabled, how are these plug-ins or the speed limits of the DSP path even coming into play?  And even if I uncheck all DSP selections, the same message appears.  The files extensions are all .dsf.

The device driver is W8.1 Wasapi directly to the Grace USB interface and has not been changed.  This whole configuration has been working fine for months.  I'm only selecting the local play zone.

Any ideas?  Am I missing something?

--Bill

[bblue]

No one has any suggestions?

Going through process of elimination, I have uninstalled all the VST plug-ins.  That made no difference.

I have two DAC's on two separate USB root ports, my Grace M905, and also a Mytek Stereo192-DSD-DAC.  Both behave in exactly the same manner when selected for output.  As I mentioned, this same configuration has worked for months, and I'm using the same files for testing.  I've tried different payload values (32-bit native and 24-bit in a 32-bit container) makes no difference.

When the song is set to play, there's a full scale thump, followed by 1/4-1/2 second of audio, and then 1/2 second of hash, followed by another full scale thump, and silence.  According to MC, the song is still playing.  If you let it go to the next dsf file, the thump-audio-hash-thump will repeat again and then remain silent for the rest, and so on.

I'm not seeing the error message quoted in the previous post.

I really don't know what else to try.

--Bill

[bblue]

A little more on this issue of DSF's not playing.  See the first messages for a description of what it does.  I'm now on version 147.

It seems that the problem is localized to certain tracks or whole albums -- all of which I've played many times before.

The most recent failure is an album by John Moriarity called The Duo.  I've played this many times, but not recently.  Today I tried and got the full scale 'thunk' and then nothing, even though MC showed it was playing it, and the DAC said it was receiving DSD.

I've attached an excerpt of the album here.  Could someone take a listen (or try to) and see if it plays for you?  I'm set for bitstreaming (obviously) and bit depth auto or 24 bit encapsulated 32 bit.  Many others I have just tried, play fine.  All the same 2.8MHZ x1 DSF.

Thanks.

[Matt]

Your sample file plays for me, but it's silence.

[tyler69]

Doesn't play for me. I get the same behavior bblue describes (music-crack-noise). That is for Bitstreaming.

EDIT: Same behaviour when played back as PCM.

[Matt]

Doesn't play for me. I get the same behavior bblue describes (music-crack-noise). That is for Bitstreaming.

Bitstreaming works fine here.  So does playback as PCM.

[6233638]

Whether bitstreaming or converting to PCM, I get two notes, a pop, and then silence.
Other DSF tracks I have play just fine.
Bad file? After all, a 150MB file shouldn't compress to 340KB

[Hendrik]

I agree, the file seems broken.
It contains mostly NULL data after a tiny bit of actual data.

[bblue]

After more and more file testing, it does seem to be file specific throughout.  Even down to one or two tracks out of an entire album.  My backups come up with good copies of at least all tracks on one bad album (John Moriarity) from a 4/21/14 backup.

What is puzzling is that I have never played any of the DSD files on anything but MC, and usually a full album at a time.

I examined the binaries of a good and bad file.  On a bad file:

00-0x50b   misc ascii text (probably a mix of binary as in a header)  text includes DSD, data, fmt, .h with blocks of zeros in between.
0x50c-0x3d89c all 0x4b's (K)
0x3d89d-0xd6260 assorted 8 bit chars
0xd6261-0x968005b all 0's (to end of file)

On the good file same song:

00-0x50b   misc ascii text (same as above)
0x50c-974555 assorted 8 bit chars
0x974556  start of tag data, first variable TIME, end tag data 0x974575b
0x974575c-0x974605b  zeros to end.

Difference between endpoints of the two files is 0xc6000, seems to be on an even boundary of something.  I'm not familiar with the internal format of DSD files, so maybe this info will be significant to another.

I have never had disk corruption, bad sectors, any kind of errors on the disk containing these files, yet there are several of bad ones scattered about.  This seems to have occurred somewhere between 4/1 and mid-May.  And all files follow the same pattern, and maintain their approximate length, which to my mind leaves out the possibility of disk or controller errors.

Is it possible that some interim bug occurred in one of the updated MC's that might have caused this?  I update all MC copies regularly and automatically.  It would almost seem like a library background run of some sort, but those should all be read only except for tag fields.

Also, so far, every file that has had this problem has been a native DSD download from BlueCoastRecords.  I haven't yet found a track damaged that didn't originate there, but upon download they all played fine.

I put up the original good version for download if anyone wants to examine it: "HERE"   Perhaps there's something about the layout that may cause problems under certain circumstances.

Thanks for any assist in tracking this down.

--Bill

[Matt]

Is it possible that some interim bug occurred in one of the updated MC's that might have caused this?  I update all MC copies regularly and automatically.  It would almost seem like a library background run of some sort, but those should all be read only except for tag fields.

I don't think so.

[bblue]

I don't think so.

Now a little more research and info about the DSF files.  The notation '0xnn' is a hex number, also known as 'nnh'.

1. The DSF file has a header that is 0x5c (92 bytes) in size.  Its first four bytes are 'DSD '

2. In that header at 0x13 is a 64-bit address which represents the offset in bytes from file byte zero to the end of the file.

3. Somewhere before the end of the file, but after the actual song data is a variable size block of TAG info that starts with 'ID3'.  It can also include cover art and other info.

4. At 0x5b of the header is a 64-bit address that represents the offset from the current position to the beginning of the TAG info.  (that 64-bit address can also be viewed as offset+0x50 from file position zero.)

I've examined of number of DSD x1 files and this is consistent.  EXCEPT for the BlueCoastRecords files that I have which have become damaged.  In each case both the offset address given at 0x13 for EOF, and that of 0x5b for the address of TAG info are the same.  Both point to the current EOF.

Please correct me if I'm wrong, or making a bad assumption.  But the fact that the header of the bad DSF files is still valid and has two still-valid pointers indicating the current end of file (regardless of its contents) suggests to me, that this is not any kind of filesystem or OS error which would typically be arbitrary and inconsistent in nature.  Instead, it is the action of a program of some sort, knowledgeable about DSF file structure, making calculated errors during tagging (probably) operations.  As far as I know, tagging would be the only time these files would be written to.  But that does happen frequently for all sorts of status changes of the library file.

As I haven't used any other program besides MC to access DSF files for playback and management in the library, that is most likely to be the culprit.  Now I'm not complaining or trying to point the finger at a 'bad' program.  I'm simply trying to get to the bottom of these damaged files and make sure that it either was a temporary condition during updates and does not pose a current problem, or that it is brought to the right person's attention for repair.

I'm going to re-purchase each of the albums and individual files that are damaged to see if it's an ongoing or transient issue.  Does anyone else have constructive suggestions?

--Bill

[JimH]

I don't think MC writes anything to a DSF file.  Matt would know.

Are these files stored on a local driver or a NAS drive?

[Matt]

I don't think MC writes anything to a DSF file.  Matt would know.

We write ID3v2 tags to DSF files.  It's been perfectly implemented, as far as I know.

[6233638]

I'm going to re-purchase each of the albums and individual files that are damaged to see if it's an ongoing or transient issue.

Surely you can contact the site and have the downloads re-issued rather than having to purchase them again.

Your file does not seem to be available to download again, so I can't try this myself, but if the files are somehow different from "standard" DSF files, I suppose it's possible that tagging them may be causing problems?

I don't think MC writes anything to a DSF file.  Matt would know.

DSF files do support tagging. DFF do not.

[bblue]

I don't think MC writes anything to a DSF file.  Matt would know.

Are these files stored on a local driver or a NAS drive?

They're on a 55T mirrored array on a dedicated server.  It also runs MC but just as a library server.

[bblue]

Surely you can contact the site and have the downloads re-issued rather than having to purchase them again.

You'd think.  I requested same a couple of weeks ago and received no response.  Am about to try again.  If no, then a re-buy is not a big deal.

Your file does not seem to be available to download again, so I can't try this myself, but if the files are somehow different from "standard" DSF files, I suppose it's possible that tagging them may be causing problems?

Which one?  The bad DSF file was attached to a message, but there was another with a link to my dropbox for a good copy.  They should still both be available as far as I know.

I'm no expert on DSF file structure, but from the files I've compared and headers I've looked at, the BlueCoastRecords recordings seem just like the others, but are the only ones affected that I've found so far.  Downloads from other HD sites seem fine.

[JimH]

What is a 55T?  55TB?

[bblue]

yes.

[bblue]

I downloaded the official DSF format document from Sony to get further details about the various values appearing in the DSD header.  I've attached it for those who might be interested.  Of particular note is the 8-byte sequence at 0x0c which is the total file size, and the 8-byte sequence at 0x10 which points to the ID3 data at the end of the file.  Of occasional significance is the 8-byte sequence at 0x54 is the size of the data chunk.  All other values in that header remain consistent.

The pattern I'm seeing in every defective file is that the total filesize is always reduced, sometimes significantly.  The ID3 data pointer may be pointing to the original correct location (before the file was truncated), or to the end of the file if the file has been reduced in size to end before where the ID3 tag used to be.  The data size pointer is usually still indicating the original size unless the filesize has been reduced significantly.  I've attached some file compares that demonstrate these header differences.

It's clear to me at this point that under certain conditions a program that is updating or adding ID3 tags is miscalculating the file size, which also affects the ID3 position and data chunk size to varying degrees.  This all results in missing music data, missing ID3 data, or mis-positioned transitions between them.  And since I only use MC ...

I have located over a dozen files from Blue Coast Records which all have been damaged by this and have been able to replace them and do comparisons.  I'm sure there are more.  Until today, however, no other commercial DSF files like from HD Tracks had been found.  Today I found one that behaved totally differently than the others (which just played 1/2 second of music, pop, silence).  This one had about 1/2 second of hash at the song beginning, and then played correctly to the end.  What was very surprising was that the header data described above was off just like all the others.  At the moment it seems that how the problem manifests itself in audio has to do with the total file size (length of the song) which affects how the file truncation and redistributed pointers move things around.

The image Rolling-compare.jpg compares the header of the bad version (top window) and good version (bottom window).  This is from Blue Coast.  The image summertime-compare.jpg is from HD Tracks and behaves totally differently when you play it, but has the same type of header defects.
You can download summertime: "HERE" if you'd like to examine it.

I hope all this is helpful.

--Bill

[JimH]

How big are the files?

[bblue]

How big are the files?

Do you mean the size of the 'smaller' Blue Coast files, vs the HD Track file?  I don't recall exactly as I'm not at my workstation right now.  But I believe the 'smaller' files are in the low 200MB typically and the larger are in the high 200's.

If you look at the comparison charts I posted, you can get a precise number representing the size of good and bad versions of the same song at the 64 bit address at 0x0c of each chart.  The -bad versions are those that were incorrectly modified, and the non-bad are the originals.  I think the compressed file of summertime on dropbox is 150MB or so.

Does that help?

[bblue]

I hate to bring up another variation of what seems like a similar issue, but I have recently run across a native 192k PCM file, also purchased from Blue Coast Records that now stutters randomly on every track.  By randomly I mean every song, but different places in each song respectively.  Repeated plays of the same track result in stutters in exactly the same place every time (and on any flac capable player).

I pulled out the FLAC headers doc and compared the layouts for a bad (stuttering file) versus one that is as these were originally. 

1. The headers are essentially identical.  On the original, the audio payload starts at 0x9ee and there's just a basic IDV3 block.  On the bad version, cover art and the R128 data has been added, and other information that MC adds.  The audio payload starts at 0x83aa and in both cases there is clear and obvious padding ahead of the audio block.

2. The audio payload on the good file is 100,764,135 bytes in size, whereas on the bad file it's 105,286,119 bytes in size.

3. The audio Overall Bit Rate on the good file is 5027274, and on the bad is 5254432.

4. The audio Total samples is the same on each: 30787680.

5. The audio Duration is the same: 160352

6. The MD5 checksum of original audio is the same between the two files.

7. I did some tests with metaflac, including removing all META DATA blocks and padding except the audio stream in both.
    metaflac --removeall --dont-use-padding <filename>
    None of the parameters above except the audio payload location.  The bad file still stuttered just the same

8. The 'good' file crashed metaflac which also corrupted the target file.  I had to remove the --dont-use-padding option to get it to complete correctly.  There was a good amount of padding remaining before the audio block, but other header values remained the same.

Other experiments with metaflac indicated that whether you add or subtract META DATA blocks, the audio block is relocated correctly and remains identically the same size and bit rate.

So how did the bad version of my file have changed audio block size and bit rate values?  It's almost as if the process that added the additional META DATA blocks uncompressed the audio payload and then recompressed it at a different compression rate.  But I don't see why if routines exist to manage the reorganization without changing the audio payload.

And as is with my DSF file issues, this PCM album has been in the MC library since I purchased it and has not been played by other software.  I'm still looking for others that might have issues.

I'm wondering if the fact that metaflac was unable to process the original 'good' file when padding was not preserved, might indicate a structural problem of some sort with the original that might be causing MC some grief under certain circumstances.  That might explain why these problems show up only occasionally.

Is anyone interested in copies of both the good and bad file versions for a more detailed comparison?  Not knowing how MC approaches these conversions I can't go much further in diagnose other than to report what I have observed.

--Bill