[Scilab-users] Unexpected END OF FILE

[Stéphane Mottelet]

Le 31/01/2019 à 07:27, Stéphane Mottelet a écrit :
> Hello Frederico,
>
> We just fixed it for Scilab 6.0.2, see
>
> https://codereview.scilab.org/#/c/20688/ 
> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20688/>
>
> S.

I mean, the doc says that binary mode for writing or reading is the 
default but it was not the case under Windows, where *text* mode was the 
default, and in this mode char of hex code 1A is EOF (in binary EOF is 
just a condition not a char).

S.

>
> Le 31 janv. 2019 à 01:20, Federico Miyara <fmiyara at fceia.unr.edu.ar 
> <mailto:fmiyara at fceia.unr.edu.ar>> a écrit :
>
>>
>> Antoine,
>>
>> Thank you VERY MUCH!
>>
>> That works. Is there a fundamental reason why not specifying binary 
>> fails somewhere? Some sort of EOF code that may present itself 
>> randomly according to file content?
>>
>> Regards,
>>
>> Federico
>>
>>
>> On 30/01/2019 20:07, Antoine ELIAS wrote:
>>> Hello Frederico,
>>>
>>> On Windows, you should open your file in binary mode, with "rb".
>>> --> fd = mopen("440Hz_0.2s.wav", "rb");
>>> --> h = mgeti(1000, "uc", fd);
>>> --> size(h)
>>>  ans  =
>>>    1.   1000.
>>>
>>> --> dec2hex(h(1:5))
>>>  ans  =
>>> !52  49  46  46  84  !
>>>
>>> Regards,
>>> Antoine
>>> Le 30/01/2019 à 23:02, Federico Miyara a écrit :
>>>>
>>>> Dear all,
>>>>
>>>> I'm trying to read data from a file (in this case a wave file) with 
>>>> the following code (Scilab 6.0.1)
>>>> fid  =  mopen('g:\Mis documentos\Ondas\440Hz_0.2s.wav',  'r')
>>>> mseek(0,  fid)
>>>> h  =  mgeti(1000,'uc',fid)
>>>> I should get a vector with 1000 unsigned 1 byte integer components 
>>>> but I end with only 164 entries. Viewing the file with an hex 
>>>> viewer, the last correctly read data are
>>>>
>>>> 34 3E 34 3E
>>>>
>>>> (decimal 52 62 52 62)
>>>>
>>>> Then the following data and further data
>>>>
>>>> 1A 3D 1A 3DÂ  ...
>>>>
>>>> are not read at all. No warning like having reached EOF. By the 
>>>> way, the repeated pairs are because it is a stereo file with 
>>>> identical left and right channels.
>>>>
>>>> The same happens changing the way the file data are to be decoded. 
>>>> Seems to get stuck when 1A or 1A 3D appears.
>>>>
>>>> Any idea of what may be going on and how to solve it?
>>>>
>>>> Federico Miyara
>>>>
>>>>
>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users at lists.scilab.org
>>>> http://lists.scilab.org/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.scilab.org
>>> http://lists.scilab.org/mailman/listinfo/users
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org <mailto:users at lists.scilab.org>
>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 
>> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190131/d5b62341/attachment.htm>