jevinskie / sacd-ripper-google-code

Automatically exported from code.google.com/p/sacd-ripper
GNU General Public License v2.0
2 stars 2 forks source link

[Foobar] Chunk size too large error #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Install DSDIFF Decoder component
2. Load .dff tracks to foobar 2000
3. Playback error pops up

What is the expected output? What do you see instead?
For a different DSD file download from the internet it plays fine in foobar but 
for some reason the ones created by sacd-ripper are unable to be loaded. I've 
tried play around with the advanced settings and set different sample rates 
with no avail.

What version of the product are you using? On what operating system?
I've tried both r191 and r198 both yields the same result.
foobar2000 v1.1.7 on Windows XP powered by VirtualBox

Please provide any additional information below.
http://www.foobar2000.org/components/view/foo_input_dsdiff

Original issue reported on code.google.com by metro...@gmail.com on 12 Jun 2011 at 6:31

Attachments:

GoogleCodeExporter commented 9 years ago
thank you for your report! this was indeed a bug and has been fixed in the 
latest trunk.

Original comment by mr_wic...@hotmail.com on 12 Jun 2011 at 9:03

GoogleCodeExporter commented 9 years ago
I'm afraid I think it's not quite fixed in version 199.
I had the same problem with the Babatunde Olatunji Circle of Drums SACD.
With 199 the first five tracks can now be played/converted in foobar.
However the last track (6) does still give:

Unable to open source file: Chunk size too large
Conversion failed: Chunk size too large

This last track is by far the largest, btw.

I used mch DSDIFF (DSD) for this one.

I can check again with version 200, if that makes any sense?

Original comment by lich000k...@yahoo.de on 12 Jun 2011 at 11:37

GoogleCodeExporter commented 9 years ago
Sorry about that, I will have to look at it once more.. Thanks for the report 
though!

Original comment by mr_wic...@hotmail.com on 12 Jun 2011 at 1:29

GoogleCodeExporter commented 9 years ago
Attached you'll find a small utility I've written to take a 8kb sample from the 
header & footer. Please run that against the non working file. I cannot 
replicate and I don't see the bug at this point. This will help me speedup to 
find out what's going on.

Cheers

Original comment by mr_wic...@hotmail.com on 12 Jun 2011 at 3:03

Attachments:

GoogleCodeExporter commented 9 years ago
Ok, here is the sample.

btw, It only happens for mch, not for 2ch

Original comment by lich000k...@yahoo.de on 12 Jun 2011 at 4:42

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for that. And interesting, the audio size is negative for this track. 
uint32_t overload, I'll check it out..

Original comment by mr_wic...@hotmail.com on 12 Jun 2011 at 4:47

GoogleCodeExporter commented 9 years ago
Indeed int32_t overload, verified; ssize_t is 4 bytes instead of 8. 

Can you confirm that the track size is larger than > 2GB?

Original comment by mr_wic...@hotmail.com on 12 Jun 2011 at 4:59

GoogleCodeExporter commented 9 years ago
Yep, it's 2.53 GB.

Original comment by lich000k...@yahoo.de on 12 Jun 2011 at 5:06

GoogleCodeExporter commented 9 years ago
I'm sorry you had to rip these tracks again and again. I know it's taking 
really long for these mch tracks. But the software is getting stable because of 
detailed reports like these! And this bug was unrelated to the previous..

It has been fixed in the trunk, please verify.. (again! :))

Original comment by mr_wic...@hotmail.com on 12 Jun 2011 at 5:12

GoogleCodeExporter commented 9 years ago
Never mind. I'm glad if I can make an (ever so tiny) contribution to your 
awesome work.:-)

Everything looks fine now.

It's not any faster than before 201, though, still ~1 MB/s

Original comment by lich000k...@yahoo.de on 12 Jun 2011 at 6:15

GoogleCodeExporter commented 9 years ago
Good, case closed, "again".

>It's not any faster than before 201, though, still ~1 MB/s

I've conducted speedup tests with negative results. With the current DST 
decoder (the one from Sony), it won't be any faster unfortunately.  Our best 
bet is a revised version of the Philips DST decoder for the PC, but that's a 
long shot.

Original comment by mr_wic...@hotmail.com on 12 Jun 2011 at 6:38

GoogleCodeExporter commented 9 years ago
I was wondering why the dsdconverter App on my mac could not read the 
multichannel DSD and DSDIFF files, I extracted with sacd-ripper version 0.3.5 
(actually the current one). When I installed foobar2000 on my win7 vital 
machine it stated exactly the same reason for not processing these files, as 
you stated above. The chunk size is too large. Only very few multichannel files 
work, but all stereo files by now. So here is my question: can I still find the 
201 somewhere on the internet?

Original comment by awi...@googlemail.com on 6 Jan 2012 at 6:46

GoogleCodeExporter commented 9 years ago
@awisus

No need to look for the older version. This is a new bug. What's the size of 
the files that do work? Are they smaller than 2GB? Do all the stereo files 
work? 

And please open up a new issue for this..

Original comment by mr_wic...@hotmail.com on 6 Jan 2012 at 8:54

GoogleCodeExporter commented 9 years ago
@awisus

and are these edit master exports or individual tracks? are the files that do 
not work larger than 4GB?

Original comment by mr_wic...@hotmail.com on 6 Jan 2012 at 8:59