Print

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

[sandalaudio]

Hello

I purchased a few large DSD256 DSF files that are over 4GB per file (20min+ long movements in classical music).

Playback was fine, but as soon as I try to edit the tags in JRiver 24, the file itself is now corrupted and shrunk to a much smaller size.

On the example screenshot attached, Windows Explorer shows the original DSF file was 4,608,826KB, but after tag editing in JRiver it changes to 414,561KB.

The file used to play for 27min 52seconds but after tag editing JRiver abruptly stops playback at 2min 30seconds.

This is not specific to this particular file, but I had this happen on several DSF files over around 4GB. Cleaning the tags or replacing the coverart etc also causes this corruption issue.

Tag editing in DBPoweramp seems to work OK and doesn't corrupt the file like JRiver did.

Is there any way to solve this? Thanks

[~OHM~]

look again the original files HAVE to be there unless you deleted it or there is a HUGE problem with MC, My bet is on the first if there gone.

[swiv3d]

Are you using a 64bit operating system and a 64bit version of MC? I suspect that you are using a 32bit version of MC on a 64bit operating system?

[sandalaudio]

Thanks for the responses

look again the original files HAVE to be there unless you deleted it or there is a HUGE problem with MC, My bet is on the first if there gone.

Unfortunately I have this folder open on Explorer to observe the file as JRiver applies the tag, and the particular file does appear to change size on Explorer.

Are you using a 64bit operating system and a 64bit version of MC? I suspect that you are using a 32bit version of MC on a 64bit operating system?

I am using Windows 10 64 bit with latest updates, with JRiver 24.0.41 64 bit. I re-downloaded the original DSF file from the store and tried the tagging thing many times, but the corruption/truncation problem happens every time.

The corrupted file can be opened in Foobar, which says it is 27min 52sec long, and it starts playing fine, but it too stops playback abruptly at 2min 30sec just like with JRiver. It seems like the file is physically chopped off at this point.

The bottom line is that the file plays all the way until the end without any issues if I don't do any tagging in JRiver.

[swiv3d]

Just to check, if you click on help>about media center    does it say Media Center 24.0.41 (64bit), or just  Media Center 24.0.41

[Spike1000]

As a test try tagging in MP3Tag.

Note: It may take a good few seconds to write the changes to a the new file and then delete the original when you commit the changes and save!

Spike

[sandalaudio]

Just to check, if you click on help>about media center    does it say Media Center 24.0.41 (64bit), or just  Media Center 24.0.41

Yes it is a 64 bit version of JRiver 24. It does say (64bit) on where you indicated.

As a test try tagging in MP3Tag.

I just tried MP3Tag for the first time, and that also corrupts the file to almost exactly the same size as JRiver does.

So far the only sure way to add and edit tags on my 4GB+ DSF files are to use right click context menu on Explorer for the DBPoweramp tag properties. This correctly modifies the tags, correctly reflects in JRiver (screenshot attached), and does not corrupt the file. As soon as JRiver touches these tags it gets corrupted.

[swiv3d]

Just out of interest as it might be relevant, how many GB of memory does your machine have?

[sandalaudio]

Just out of interest as it might be relevant, how many GB of memory does your machine have?

I have 16GB with less than half utilized.

I have experimented a bit, and found that first time I play the file it is fine but the second time it abruptly cuts out at 2:30. It may be because the tag for playback count is being added automatically? The weird thing is that this does not truncate the filesize like it does with manual tagging. When I play this file in other programs (Foobar, TuneBrowser etc) it plays all the way to the end but sounds buzzy and noisy after 2:30 onward. The only way to listen to the full track without issues is to play fresh as downloaded.

I thought maybe the file itself is corrupted to begin with, but I have three DSD256 DSF files over 4GB+ from different labels (Channel Classics and Challenge Records), and they all have this issue with JRiver. All other files less than 4GB are fine with tagging and playback. I know it is a rare case, but does anybody have a similar 4GB+ file that works well on their system? It's really worrying because as soon as the file is corrupted there is no way back, and it's a pain to re-download the same track again from the shop.

[swiv3d]

As a short term measure I would make copies of any files over 4GB and keep them in a folder that is not used by MC, that way you won't have to download them each time. Hopefully this will be looked at.

[Hendrik]

I couldn't spot anything obviously wrong in DSF tag writing (without a file that size at hand). Do the files already have any tags when you get them?  And, as far as you can tell, does MC manage to read them?

[sandalaudio]

I couldn't spot anything obviously wrong in DSF tag writing. Do the files already have any tags when you get them?

The album is supplied as ZIP of a folder containing all the DSF tracks. I noticed that the tracks less than 4GB have tags embedded as purchased, but the problematic file greater than 4GB does not have any readable tags. I noticed this in several albums.

It could be that the particular software that the record labels are using to embed that tags is somehow not compatible with 4GB+ files? I am wondering whether I can re-encapsulate DSF-ISO-DSF or DSF-DFF-DSF to clean up these files. It's hard to figure out whether it's a record label or a Windows or a JRiver problem.

As a short term measure I would make copies of any files over 4GB and keep them in a folder that is not used by MC, that way you won't have to download them each time. Hopefully this will be looked at.

Thanks. As soon as I realized this is happening, I started re-downloading and keeping the original files in a safe place outside the JRiver library scans.

I don't have many of these exotic files so I can always use other programs to listen to them as needed, but I would like to figure out what is going on. I guess this is a reason why it's not a good idea to go over the top and buy these crazy high resolution files, but the curiosity always wins over common sense.

[Hendrik]

I do wonder if maybe the tags are "wrong" as provided by the shop you got them from. In the header of a DSF file it indicates the position where tags are supposed to be found. If this position would be wrong and point right in the middle of the DSD data, then I could totally see MC trying to write new tags resulting in such an issue.

We could possibly try to detect such a case, but I might need a file to see how exactly it looks, so thats not so easy.

Edit:
I did add a small safety check that tries to validate if the tag data indicated by the header is ID3 data before trying to overwrite it. Maybe this will help if the above theory is correct.

[Awesome Donkey]

I've never seen a 4GB+ DSF file. Where are these sold at? I'd try to create one to test this, but I don't have any SACD ISOs remotely close enough to 4GB in size - the biggest one I have is around 3.5GB in size.

P.S. Hendrik, while you're looking at the DSF tag writing, could you please look into why the Album Artist tag is doubled with DSF files (especially after setting the Album Artist tag in MC and running Update tags (from library) - you can verify the double tag in foobar2000 and dBpoweramp)?

https://yabb.jriver.com/interact/index.php/topic,114704.0.html

[Hendrik]

DSF file tags are not special, they just write ID3v2 tags.

[Awesome Donkey]

DSF file tags are not special, they just write ID3v2 tags.

This is true, however the strange thing is the double/duplicated Album Artist tag issue happens with only DSF and AIFF files, but it's also easily reproducible. MC doesn't display the tag as duplicated in the tag window, but viewing the file's metadata in another app (e.g. foobar2000 or dBpoweramp) shows the Album Artist tag is doubled, especially after using Update tags (from library) to write/update the tags. My theory is it's writing Artist and Album Artist to the Album Artist tag accidentally. I should be able to test it and verify if that's indeed the case.

EDIT: Nope, my theory is incorrect. It's simply duplicating Album Artist.

[swiv3d]

Tag editing in DBPoweramp seems to work OK and doesn't corrupt the file like JRiver did.

If you look at one of the uncorrupted large files with DBPoweramp is there any metadata present? If DBPoweramp can tag the files without corrupting them it looks like a 4GB limit is present in MC as far as tagging goes.

[Awesome Donkey]

If DBPoweramp can tag the files without corrupting them it looks like a 4GB limit is present in MC as far as tagging goes.

If that's the case, any file over 4GB in size should experience the same file corruption issue. However, I don't think anyone with 4GB+ video files have reported any issues with file corruption after editing the metadata.

My guess would be it's limited to 4GB+ DSF files. I suppose the easiest way to help the devs with this one would be to provide a 4GB+ DSF file for testing. Or attempting to convert a DSD file to DSD256.

[swiv3d]

Ok so I created a 4.2 gb dsf file from a 1.08 gb Miles Davis track, changed the genre tag and saved it ... no change in file size occurred.
Now playing it to see if it fails at some point but my guess would be that it will play through.

EDIT: -  Played all through. Number of plays updated in the tags correctly

[Hendrik]

My guess remains that the original files had corrupt tagging information, which resulted in this bug manifesting. Hopefully the next version of MC should avoid truncating the files - at the expense of just not trying to write tags to them if it detects them as being corrupted like that.

[swiv3d]

Sandalaudio
I know channelclassics and use them a lot. You could raise this withthem to see if they have any ideas. You might also as an experiment try unzipping a folder with 7zip which is free and usually performs better than the windows extractor - just to see if it is the unzipping process which is causing the problem. A longshot but channelclassics have commented to me on occasion that unzipping folders has caused problems in the past.

[kr4]

If that's the case, any file over 4GB in size should experience the same file corruption issue. However, I don't think anyone with 4GB+ video files have reported any issues with file corruption after editing the metadata.

My guess would be it's limited to 4GB+ DSF files. I suppose the easiest way to help the devs with this one would be to provide a 4GB+ DSF file for testing. Or attempting to convert a DSD file to DSD256.

I have numerous DSFs in excess of 4GB (up to 14.5GB) and they tag without truncation.

I know channelclassics and use them a lot. You could raise this withthem to see if they have any ideas.

Good idea.  I have had 1-2 issues with their tagging in which the EOF was not consistent with the actual file size.  Might be relevant.

[sandalaudio]

Thanks for all the insight

I do wonder if maybe the tags are "wrong" as provided by the shop you got them from. In the header of a DSF file it indicates the position where tags are supposed to be found. If this position would be wrong and point right in the middle of the DSD data, then I could totally see MC trying to write new tags resulting in such an issue.

Examples of albums I have issue with are
https://www.challengerecords.com/products/14851639216103
https://www.challengerecords.com/products/1330078616
https://www.channelclassics.com/catalogue/38817-Mahler-Symphony-no-3/

all of there are available for purchase as DSD256 (11.3MHz) DSF files, where one track exceeds 4GB (approx. 20min +).

My guess remains that the original files had corrupt tagging information, which resulted in this bug manifesting. Hopefully the next version of MC should avoid truncating the files - at the expense of just not trying to write tags to them if it detects them as being corrupted like that.

This seems like the most probable cause. I can imagine that many record labels are using the same mastering and authoring software to package the DSF, and this might be adding bad tags. I wonder if there is a way to fix this on my files.

If it was a FLAC/ALAC files I can always extract them as WAV/AIFF and re-encode them which usually fixes these tagging issues. With DSF I don't know of any way to do something like that.

[sandalaudio]

Thanks for all the help. Just an update on the situation

As people suggested, it seems like the original file does have tags embedded but the file header is pointing to a wrong location.

I tried using another program (TuneBrowser) to tag this file, and it spits out the following error (screenshot attached).

Block count 2359714560 cause fraction in final DSF page (768 bytes).
This file is normal fraction storing style.
Error: ID3 chunk is on the wrong place.
Error: Fail to remove old ID3 chunk.

Not sure exactly what this means but it certain seems like the original file is at fault. The annoying thing is that the same error occurs on all of my 4GB+ files I purchased from Channel and Challenge. I will contact the labels to figure out a solution.