LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

yEnc

Solved!
Go to solution

I'm trying to implement a yEnc Decoder in LabView. The attached solution seem to be working most of the time with small txt files, but when I'm trying to decode larger files, i.e. with .rar extension etc. from usenet groups, the encoder doesn't quite work. It seems to add random bytes extra, and I don't know where this is comming from.

I'm not 100% sure if I'm decoding the binary file corectly, but the yEnc Encoding is pretty simple from what I've seen.

 

 

Attached are yEnc Decoder VIs and two files, one where it wirks and one where it doesn't.

 

Any help appriciated.

 

Thanks

 

Kas

0 Kudos
Message 1 of 9
(3,562 Views)

Yes, your code is 'ok' for small size files.

The same code is not ok for large size files, because the decoding step(Step #3) is processing every byte by byte.

It will take lot of time to complete the operation.

 

You have to change the logic for conversion.

Some suggestions:-

1. Use 'For Loop' for decoding and use progress bar for the status.

2. 'String to Byte Array' conversion should happen in only once. (move before the 'For Loop', not inside)

3. Use Boolean flag for 10,13 or 61 not numeric.

 

Regards,

Yogesh Redemptor

 

 

 

Regards,
Yogesh Redemptor
Message 2 of 9
(3,548 Views)

Thanks for the reply.

My aim was initially to get it to work. And I agree, this is a dirty way of doing it, but if the concept or the code works, then I can go back and make improvements on speed etc. The way I have it, as you mentioned, works for small, but why not for big. I know I'm dealing in bytes, but thats the only way to deal with when using yEnc (as much as I can tell), purely because the way that yEnc is encoded. Is possible if you can demonstrate where exactly I'm going wrong? It might be something imple, but I just can't figure it out.

 

Thanks

 

Kas

0 Kudos
Message 3 of 9
(3,538 Views)

Hello Kas,

 

I am appreciating your interest and mail.

Please find the attached solution.

It have your method as well as new method for comparison.

Still It is not completely optimized. You can have your hand in it.

 

Suggestions:-

1. Don't feed all the data(string) at single time, but feed the data batch by batch to avoid huge memory allocation.

2. Remove the OpenG functions and have custom built functions.

 

Regards,

Yogesh Redemptor

 

Since I have attached the OpenG functions, one attachment size is big;

If you have installed the OpenG library, you can download only the 'yEnc Decoder.vi'

 

Regards,
Yogesh Redemptor
Download All
Message 4 of 9
(3,508 Views)

Thanks again for your reply Yogesh. I had something similar in mind by replacing and deleting indicies in bulk, but nice adition with the array function inside for loop, I wouldn't have thought of that, and yes, the OpenG will have to be replaced.

 


To some better knews, I got the whole encoder working. To my surprise, is wasn't the Decoders fault. It was allready programmed to the specification. The problem seems to be with NNTP and POP3 Servers. Apparently, If a line starts with a "." (i.e. any of the 128 Byte lines on the encoded binary) than the NNTP server and apparently POP3, introduces an extra "." to it. i.e. if a line starts with ".$£%^&" etc", when downloaded, it becomes "..$£%^&". In this case, than I just delete one of the "." and it works. The Code is attached.

 

This introduces a new wrinkle on the code. I don't really want to place each line "with pick line function" into an array and examine the first two characters for "..", mainly because I'll be dealing with large files. Is there a way of optimising the above code "this may turn into a trade of between processor speed and memory" with this extra functionality?

 

For majority of the attached code, I can replace with something similar to what you've done. Is there however a clever way of implementing this new ".." function? This ".." property is only for the first TWO bytes of the line (i.e. the first 2 bytes of 128 byte line).

 

P.S. Now the "NOT WORKING" example actually works as well. This can be confirmed by checking the header of the binary file in the string indicator, the displayed size in the indicator is the same as the decoded size of the array at the end.

 

Also, I'm not sure if you know LAVA Forum, its similar to the NI Forum. I've also opened the same post on that side. Link:

 

http://lavag.org/topic/16252-yenc-decoding/

 

You may continue here, but when we complete the post, I will link them both at the end so this can serve as a benefit for both forum users.

 

Thanks again

 

Kas

 

0 Kudos
Message 5 of 9
(3,491 Views)

Have look over at lavag.org, I posted a version that reuses the input buffer to hold the decoded data.

 

/J

Message 6 of 9
(3,477 Views)

Thanks

 

 

Kas

0 Kudos
Message 7 of 9
(3,473 Views)
Solution
Accepted by topic author zerotolerance
Message 8 of 9
(3,469 Views)

This thread is now considered COMPLETE, and moved to Lava.org forum:

 

http://lavag.org/topic/16252-yenc-decoding/page__pid__99276#entry99276

 

Regards

 

Kas

0 Kudos
Message 9 of 9
(3,462 Views)