Fri 01 Nov 2013 08:26:23 PM UTC, comment #10:
According to Lev's e-mail reply the issue was solved in the meanwhile.
|
Fri 01 Nov 2013 01:13:05 PM UTC, comment #9:
The link to 385.mat is broken again.
@Jordi or David: can you please upload the file again?
Regards, Andy
|
Thu 04 Aug 2011 05:58:36 AM UTC, comment #8:
Thanks, Levente. I've re-uploaded the file here:
http://jordi.platinum.linux.pl/octave/385.mat.zip
|
Thu 04 Aug 2011 03:03:39 AM UTC, comment #7:
I'll send them off line as even compressed in tar.bz they are 2MB in size
D.
|
Thu 04 Aug 2011 02:41:02 AM UTC, comment #6:
The Rapidshare links are broken now. Also, I saw that matio speaks of an old bug in zlib 1.2.2 that could be related to thihs, but I think you had 1.2.3 in your install. Can you please email me your .mat file and I'll host it in my server? I'd like to prod this problem.
|
Sun 06 Feb 2011 02:41:35 PM UTC, comment #5:
After having looked at this for a few hours I don't understand what is going on, but we probably need to directly use the zlib inflate function rather than the uncompress utility function to allow fine detail on how we uncompress the data.
Thinking about it, I wonder if we aren't just better off taking the matio (http://sourceforge.net/projects/matio/) library that also knows how to read matlab v7.3 files and using it to replace all of the Octave matfile code. The only disadvantage I see of doing this is that matio doesn't know how to handle matlab Objects and so saving/loading anonymous function handles and function handles would need to be added to matio code to allow it to be used with Octave, but that might be easier than getting the matlab v7.3 stuff right ourselves. Though this should be thought about for 3.5 rather than 3.4
In any case I'll try again to fix this using directly the zlib inflate function as a quick fix for 3.4
D.
|
Thu 20 Jan 2011 09:15:05 AM UTC, comment #4:
To get a better idea of what the error might be, I checked in the following changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/e306683a7e97
and I'm seeing a "data error" from zlib's uncompress function.
Looking at http://www.zlib.net/zlib_how.html, it seems that this error means that "either the data is not a zlib stream to begin with, or that the data was corrupted somewhere along the way since it was compressed"
I'm not sure where to look to debug this problem. Are we using zlib incorrectly?
I'm adding David Bateman to the CC list for this report since I think he was the original author of the code that interfaces with zlib.
|
Wed 19 Jan 2011 11:05:01 AM UTC, comment #3:
In addition to that, if I save in matlab v4 format I can successfully load it in octave. I suspect the that decompression is buggy in octave.
|
Wed 19 Jan 2011 10:47:38 AM UTC, comment #2:
I tried to create a file that leads to the same bug as this one but is shorter but I cannot.
This file has a few variables such as
bits 1x1 8 double
brand_ID 1x1 8 double
brand_name 1x7 7 char
dataID 1x1 8 double
device_ID 1x1 8 double
device_name 1x14 14 char
device_type_ID 1x1 8 double
device_type_name 1x20 20 char
fs 1x1 8 double
and the most interesting is
samples 299004x2 4784064 double
If I save the latter variable (samples) w/o other varibales in a separate file, I got the same bug.
If I save these variables w/o samples I experience no bug.
So the critical thing is in the samples matrix.
I made a matlab function that can save the content of this matrix in octave readable format. Since the file limit of .5Mb at Savannah I could share this file at some public file server such as rapidshare unfortunately:
http://rapidshare.com/files/443379892/385_3_oct.mat
Lev
|
Tue 18 Jan 2011 02:20:20 PM UTC, comment #1:
I can confirm this with octave 3.3.55 on debian squeeze.
I tried also:
file 385.mat
385.mat: Matlab v5 mat-file (little endian) version 0x0100
head -n1 385.mat
MATLAB 5.0 MAT-file, Platform: PCWIN64, Created on: Mon Jan 17 10:49:19 2011
scilab loads the file without problems:
--> debug(1)
-->loadmatfile("385.mat")
[device_name,samples,fs,bits,device_ID,device_type_name,device_type_ID,brand_name,brand_ID,dataID]=resume(Matrices(:))
device_name = PANASONIC_TXP42G10E
samples =
- 0.0001221 0.7010498
- 0.0000916 0.7004395
- 0.0000305 0.7000122
....
fs = 10000.
bits = 16.
device_ID = 96.
device_type_name = plasma_tvs
device_type_ID = 12.
brand_name = PANASONIC
dataID = 385.
@Lev I'm not an octave developer but could you provide a very simple and small .mat file which shows this error in octave?
Andy
|
Tue 18 Jan 2011 11:00:39 AM UTC, original submission:
Hi Guys,
I am using version 3.2.4 on ubuntu 10.10 (64 bit).
Interestingly I could load files saved on windows 64bit + matlab 7.10 but not all of them.
I did attach this file but you may download it from from rapidshare (1.5 MB)
http://rapidshare.com/files/443205897/385.mat
Does anybody have an idea what's wrong with this?
Thanks in advance,
Lev
|