aicodix / shredpix Goto Github PK

Then why transmission is time and size limited?
I want to send my original photo by audio via this digital method.

Look:
Better send via your app RAR archive file with include 50% of Recovery Record (which based on Reed-Solomon codes) and then recover it in background, instead of your 50% bandwidht overload by duplicating data.

No file browser, non comfortable options menu. Tested it, and i can send PNG only very small or with potato quality.
Useless app with not realized COFDMTV potential.

Anyway, with respect for your work. SSTV app coders helping with transmission photos from anals of this world to comfortable place.

It have much more image quality at same file size compared to lossy WebP or JPEG.

Assempix will require simple viewer in this case.
Or, image with higher quality can be send with conversion:
Shredpix ( image -> jxl ) --> sending JPEG XL image --> Assempix ( jxl -> png ), then no any viewer needed.

5380 bytes... this current algorithm cannot send signal as many long time as needed?

Creating the native encoder can fail if not enough memory is available.
A potential null pointer dereference has been fixed with commit adbd103
It would be nice to show the problem in the UI and suggest some solutions to the problem.

The Carrier shall be placed after the Mode, because its ranges depend on the Mode selection. (Even if the values near min and max will rather never be used.)

Current:

Suggestion:

(The line weights are 10, 10 , 9 and 8, and EditText "Call" has layout_height="wrap_content".)

For external usage, storing and using audio file at any time with any applications and conditions.