I've got a sequence of 28 bytes, which are supposedly encoded with a Reed-Solomon (28, 24, 5) code. The RS code uses 8-bit symbols and operates in GF(28). The field generator polynomial is x8+x4+x3+x2+1. I'm looking for a simple way to decode this sequence, so I can tell if this sequence has errors.
I've tried the Python ReedSolomon module, but I'm not even sure how to configure the codec properly for my RS code (e.g. what's the first consecutive root of the field generator polynomial, what's the primitive element). I also had a look at Schifra, but I couldn't even compile it on my Mac.
I don't care too much about the platform (e.g. Python, C, Scilab) as long as it is free.
I successfully built an embedded data comms project that used Reed Solomon error correction a few years ago. I just had a look at it to refresh my memory, and I found that I used a fairly lightweight, GPL licenced, C language subsystem published by a well known guy named Phil Karn to do the encoding and decoding. It's only a few hundred lines of code, but it's pretty intense stuff. However I found I didn't need to understand the math to use the code.
Googling Phil Karn Reed Solomon got me this document.
Which looks like a decent place to start. Hope this helps.
Related
I'm using Embarcadero C++Builder 10.1 Berlin Update 2. I'm using System.Zip.TZipFile.ExtractAll() to extract a large .zip file.
Here are the details surrounding the problem scenario:
The size of the .zip file is 387,077 KB
Using System.Zip.TZipFile.ExtractAll() to extract the .zip file, we end up with:
a 4,194,304 KB size file.
The data is truncated.
Using Windows OS, right click Extract All..., we end up with
a 6,035,259 KB size file.
We need all of the data out of this file.
Reading the System.Zip.TZipFile documentation, I do not see anything about limitations related to file size.
From what I know, this is Embarcadero's provided way to extract .zip files. How may I resolve this issue?
Until you tell us whether the data are simply truncated or instead somehow transformed, we can only really guess at what is going on. However, it's a well-educated guess.
Your output is precisely 232 bytes long, a familiar boundary for many older technologies.
The fact that (as you point out) the documentation doesn't state this limit, further suggests that this is just an upper bound on what the developers bothered to support, probably a very long time ago. They never imagined you'd need any more than that, particularly as many file systems didn't even support files larger than that until [relatively] recently.
Prefer modern, standard C++ and a nice third-party library for unzipping.
I'm trying to save a series of images (16 bit grayscale pgm) as video. The video has to be compressed. My program has to be independent of the codecs installed in the system.
My initial idea was to use OpenCV for this, unfortunately it depends on codecs installed in the system (unless I'm missing something).
I feel like there should be a way to compile an encoder (H264 or similar would be perfect) into the program or redistribute it as a dll with my program. I just can't find any good up to date guidance/examples.
I've been swimming in the deep vast ocean of AV encoding for a couple of days and would really appreciate it if someone could point me to a right direction.
Thanks.
As Ben suggests, it would be a good idea to use an established library in your code.
FFMPEG is probably the most used at the moment - it can be used on the command line, with a 'wrapper' program or the libraries it is built with can be used directly.
I think the last case sounds like the one you want - you can find documentation here:
https://trac.ffmpeg.org/wiki/Using%20libav*
Note the comment about disambiguation at the start - this is important to understand as the project lib and the library (which is what you want) are different things.
and there is some notes in this answer on how to build it into a program:
FFMpeg sample program
I'm trying to learn the level format in one of my favourite games, which is almost totally undocumented. Basically the only document that describes the level format is simply by saying things like First 12 bytes: header 4 following bytes: number of materials x next bytes: array of materials, and things like that.
I'm very inexperienced in hex and don't completely understand what they're saying. However, there is a level editor, and the source is freely available on google code. I was thinking of adding this in to my visual studio and trying to learn the level format by reading how the level editor opens the files.
However, another problem, I don't know c++ (I know python). This means I probably won't be able to locate which part of the code reads the bytes and whatnot.
What I'm looking for, is something that will allow me to follow the flow of the code, in its execution. Essentially something that acts similar to setting a breakpoint on every line, and having it show me what specific portion of code is executing when reading the file contents.
However, obviously setting breakpoints on every line is very messy and slow. I'm looking for something that will simply show me what code is being run when I open the file in the editor.
Does anyone know what I could do? Thanks.
You're looking for a feature to step from one statement to the next; every debugger I know has such a feature. You start by setting a single breakpoint at the beginning of the interesting region, and starting from there you "step" through your code.
E.g. in Visual C++ 2010, the key F10 does one step; you can also "step into" the next statement (e.g. a method call) with F11.
In your case, set the breakpoint to where the reading of the level file starts, and continue from there. To find the place where the file is read can be a hard problem as well - depending on the clearness of the code; but if it's well written code, there should be a method with "read" in the name or "load" or something similar - you'll figure it out!
You might have to know at least some basic C++ syntax to be able to follow what's going, though.
I would also recommend reading up on Debugging HowTo's (e.g this one).
The document wich you find so obscure, is just the level format specifications, in most cases the specifications are all you need. You need as well some little extra experience with file reading.
When reading a file you have to warry about few things.
1) When reading byte by byte (8 bits) order is no changed.
2) When reading 32bits at a time byte order can change according to endianness of machine.
(for example 0x12345678 becomes 0x78563412 when endiannes changes)
There was a very old tutorial that can help you loading 3D models that helped me to start working with files:
http://www.spacesimulator.net/wiki/index.php?title=Tutorials:3ds_Loader
this is usefull because you have part of the specifications (like in original documentation) and it shows how you can create a loader just starting from specifications. That's all you need. That's C but there is no big difference from C++ in this case.
If you need some other simple file format specification with related file loader for making things clearer to you, you can also look at libktx and ktx specifications:
http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/
If I remember correctly there's also a unofficial C++ KTX loader you can look at if you itend to write C++ oop code rather than C.
I am attempting to find documentation of the psd file format so I can read in a .psd and then save out the individual layers as files, along with do other modifications. Does anyone know of any document in on the .psd file format? (Just for reference, I will be writing this in C++)
If there are any code examples of loading a .psd file in C++ then I would appreciate them being linked.
(Please not turn this into a "just use XXX software". This is not homework, or anything related to that. I am doing this because I think it will be a fun project to work on. I will ask for posts to be down voted if this happens.)
There's also some Objective-C code on GitHub (should be easily understandable for anyone with a C++ background), also source of this gem, which appears to sum it up nicely:
At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
PSD is not a good format. PSD is not even a bad format. Calling it such would be an
insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
worked on this code for several weeks now, my hate for PSD has grown to a raging fire
that burns with the fierce passion of a million suns.
If there are two different ways of doing something, PSD will do both, in different
places. It will then make up three more ways no sane human would think of, and do those
too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
that these particular chunks should be aligned to four bytes, and that this alignement
should not be included in the size? Other chunks in other places are either unaligned,
or aligned with the alignment included in the size. Here, though, it is not included.
Either one of these three behaviours would be fine. A sane format would pick one. PSD,
of course, uses all three, and more.
Trying to get data out of a PSD file is like trying to find something in the attic of
your eccentric old uncle who died in a freak freshwater shark attack on his 58th
birthday. That last detail may not be important for the purposes of the simile, but
at this point I am spending a lot of time imagining amusing fates for the people
responsible for this Rube Goldberg of a file format.
Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
I had to apply to them for permission to apply to them to have them consider sending
me this sacred tome. This would have involved faxing them a copy of some document or
other, probably signed in blood. I can only imagine that they make this process so
difficult because they are intensely ashamed of having created this abomination. I
was naturally not gullible enough to go through with this procedure, but if I had done
so, I would have printed out every single page of the spec, and set them all on fire.
Were it within my power, I would gather every single copy of those specs, and launch
them on a spaceship directly into the sun.
PSD is not my favourite file format.
Just so you are warned. :)
This will not be a fun project, the .psd format is big. It incorporates every feature Adobe has put into Photoshop over many years.
I believe the specification can be had from Adobe, but they don't just hand it out to the public. You'll have to contact them and jump through some hoops first.
The PSD file format specification as written by Adobe is here;
http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/
Last update: June 2012. As far as I know this is the best available source about the PSD file format even there are few mistakes.
First I recommend starting by dividing PSD into blocks.
Enjoy!
MyPSD::CPSD class is a C++ class that can load images saved in Adobe's Photoshop native format.
http://www.codeproject.com/Articles/10398/Import-Adobe-Photoshop-psd-images
MolecularMatters psd_sdk seems like a good library to take inspiration form: https://github.com/MolecularMatters/psd_sdk
It allows to read layers from a .psd file and much more.
I've always been curious about audio conversion software, but I have never seen a proper explanation from a beginners point of view as to how to write a simple program that converts for example, a mp3 file to a wav. I'm not asking about any of the complex algorithms involved, just a small example using a simple library. Searching on SO, I came up with several names including:
Lame
The Synthesis Toolkit
OpenAL
DirectSound
But I'm unable to find a straightforward example of any of these libraries. Usually I don't mind wading through tons of code, but here I have absolutely no knowledge about the subject and so I always feel like I'm shooting in the dark.
Anyone here have a simple example / tutorial on converting a sound file using any of these libraries? My question is specifically directed towards C/C++ because those are the two languages I'm currently learning and so I'd like to continue to focus on them.
Edit: One thing I forgot to mention: I'm on a *NIX system.
Thanks everyone for the responses! I sort of cobbled them together to successfully make a small utility that converts a AIFF/WAV/etc file to an mp3 file. There seems to be some interest in this question, so here it what I did, step by step:
Step 1:
Download and install the libsndfile library as suggested by James Morris. This library is very easy to use – its only shortcoming is it won't work with mp3 files.
Step 2:
Look inside the 'examples' folder that comes with libsndfile and find generate.c. This gives a nice working example of converting any non-mp3 file to various file formats. It also gives a glimpse of the power behind libsndfile.
Step 3:
Borrowing code from generate.c, I created a c file that just converts an audio file to a .wav file. Here is my code: http://pastie.org/719546
Step 4:
Download and install the LAME encoder. This will install both the libmp3lame library and the lame command-line utility.
Step 5:
Now you can peruse LAME's API or just fork & exec a process to lame to convert your wav file to an mp3 file.
Step 6: Bring out the champagne and caviar!
If there is a better way (I'm sure there is) to do this, please let me know. I personally have never seen a step-by-step roadmap like this so I thought I'd put it out there.
For converting between various formats (except MP3) check libsndfile http://mega-nerd.com/libsndfile/
Libsndfile is a library designed to
allow the reading and writing of many
different sampled sound file formats
(such as MS Windows WAV and the
Apple/SGI AIFF format) through one
standard library interface.
During read and write operations,
formats are seamlessly converted
between the format the application
program has requested or supplied and
the file's data format. The
application programmer can remain
blissfully unaware of issues such as
file endian-ness and data format
It is also simple to use, with the API following the style of the Standard C library function names:
http://mega-nerd.com/libsndfile/api.html
And examples are included in the source distribution.
For actual audio output, another library will be needed, SDL as already mentioned might be a good place to start. While SDL can also read/write audio files, libsndfile is far superior.
If your curious about DSP and computers, take a look at the Synthesis Toolkit. It's sweet. It's designed for learning. The examples and tutorials they have on their website are straightforward and thorough. Keep in mind, the guys who wrote it, wrote it so they could create acoustic models of real instruments. As a result, they've included some instruments that are just plain wacky, but fun. It will give you a core understanding of processing PCM sound. And you'll probably be able to hack together some fun little noisemakers while your at it.
https://ccrma.stanford.edu/software/stk/
Check libmad http://mad.sourceforge.net " "M"peg "A"udio "D"ecoder library", should provide a good example.
Also for an easy cross-platform audio handling, check SDL http://www.libsdl.org/.
Hope that helps.