mp3guessenc / News: Recent posts

I noticed the current package has an issue.
It's not directly mp3guessenc-related but the Makefile (which I tweaked a bit by hand) will not work if you choose a different compiler than gcc. I know Makefiles are all about ease of build and lacking this feature means a real annoying bug can affect builders, testers and integrators (if any). My apologies.
The fix is easy: edit the Makefile and replace the explicit compiler name (currently "gcc" at statement 75) with the right variable $(CC) and that's all.

Recently, user Lorence sent me a full log (with lots of errors) of a mp3guessenc analysis, seeking for help.
He build the software (applying minor modifications) into AmigaOS inside an UAE environment, emulating a m68k processor.
[Briefly: the file he fed mp3guessenc with was a strange mess.
It had a regular mp3 frame, then a ID3v2 tag, then a full mp3 vbr bitstream (mp3pro, truth be told) and then a good old ID3v1. Further, in this unusual scenario, the end of the ID3v2 tag exactly overlapped the VBRI tag written by the original encoder. So, skipping different amount of bytes revealed different contents. But this is another story...]
What all this brought to my mind is: how does mp3guessenc behave on a big-endian machine?
At a glance, the answer was easy.
Audio mpeg contents are already big-endian (the very first bit is always the most significant), and with this assumption the whole code was written. So the stream detection does work.
Ok? Not really.
Raw audio bitstream aside, there are lots of metadata tags floating around. (Oh, shxt!!!)
The only thing to do was running mp3guessenc into a big-endian machine on my whole set of test files and see what happened.
No Amiga around, no MacSomething around, no SPARC workstations around, so the only solution was virtualization.
No way for VirtualBox nor VMware, they just focus on x86 architectures. It took me a couple of days getting a qemu virtual machine running a full operating system on a big-endian architecture. It wasn't me achieving this goal (qemu newbie here) but, after several failed attempts on my own, good luck brought me on this page where the blog owner offers his ready-to-go virtual machines (which, btw are incredibly light!) running debian on powerpc. Thank you Aurelien!
mp3guessenc built just fine (posix is posix, eh eh) and the test result was clear.
Indeed, the bitstream recognition was working BUT when a small tag was wrongly assumed to be several hundreds megabytes big, there was no bitstream detected at all. In fact, size fields into tags are usually written in little-endian byte order and this is how they used to be read by mp3guessenc, gaining speed from the byte order match.
Finally, a noticeable review of the tags.c module was needed. Every integer field into tags is now read as a raw byte sequence and then built on purpose as an unsigned integer. This makes the tag recognition endian-ness indipendent.
And so, the current mp3guessenc 0.27.2alpha is proudly announced to be ready for big-endian architectures too!!!
(Happy end)

Have an Italian Espresso!
The latest release of mp3guessenc is even stronger when recognizing bitstreams among junk, and it gathers ancillary stats into any layers!
Enjoy!

mp3guessenc 0.27, "Ancient Melodies Enchanting Lightnings Into Art", is now avaliable for download from the usual places.
[this release was somewhat anticipated yesterday by a 0.26.2 release fixing a single critical bug]
The music is sounding, the command line runs smooth, and the path is clear.
Have fun (and a happy Christmas too)!

My work on mp3guessenc goes on, and in these days something takes the shape of the upcoming release 0.27.
It happened that I stumbled into this useful and reliable mpeg audio decoding library (yes, the well known libmad) which OH! it is open source software so, hey, let's have a look at its inner procedures. The source code is clean and readable, and so I quickly learnt (for example) how many bits have to be taken into account when you want to check crc16 in layerI and layerII frames (for layerIII ones the amount is easy to get: it is the side information block). Furthermore, I learnt there are some reserved values when it comes to evaluate bit allocation infos (in layerI) and in some field of the side info block itself. Mmhh... useful! This turns out into a more robust frame recognition for mp3guessenc.
Having said that, from the final user point of view, no revolutions: mp3guessenc keeps on being faster and more robust (now it verifies crc16 in all layers), even with this release. It does all this even now, but the code is in the middle of a great transition and, in fact, it is an ugly mess.
Most of the news are actually on the technical side, and they are a valuable decrease in file accesses (system calls), this means even more speed, and a general cleanup of the whole process, which now reads its data from a file stream (and put them into buffers) in very few statements. And that's all! On the other hand, maybe its footprint in memory will grow up a bit... oh, well, you have a couple of spare kilobytes, haven't you?
Taking this path will involve wrapping the core functions into a well defined bound, which in turn means enclosing features into a library. Well, in the middle-term, I mean.
Stay tuned for some releases in the next weeks... I'm having fun with mp3guessenc.
And you'll have too!

Yes, time flies, it's already been a month but nevertheless a new further release is coming.
Here you have the most cryptic and darkest, yet the most well tested and rock solid release so far.
It's BLACK.
0
26
1
Enjoy!

Well, it's been a while with no releases, and some things have changed here, in "real life".
mp3guessenc is now quite stable and still is growing very well!
Try building it for your Android device ;-) and have fun!
Get this new Hotel Torino!

It's been a while without releases, but many little modifications went into the project during my spare time. So, what once was 0.25.3, it has grown and became the beginning of 0.26 - or at least, a juicy preview!
Enjoy!

Now, it's hot!
Get the latest release of mp3guessenc, with not-so-many shiny new features, BUT with enhanced accuracy, speed and reliability.
Be "Fuori Dal Tempo"!

It was in a sunny sunday (yesterday) when I found myself having a couple of hours of real spare time.
My migration to LMDE 201403 was successful -- it's really nice, it really sparkles my eyes!
I've read up to the last page of a great book by Carlos Ruiz Zafon and - as usual - I want to keep my feelings warm for a week or so before takin' a new one.
I was too lazy for a football match with my friends.
So I just had my afternoon coffee and I thought: "this is the right time for enhancing mp3guessenc with that tiny little change I always wanted to have" - fool me.
The issue is: in a bunch of old (ancient) mp3 encodings a broken last frame may be found. After a good analysis, it reveals as not broken, the bit stream is valid, but the encoder evaluated that a whole frame was a waste of bytes and it built an incomplete frame, putting in just part2+part3 of audio data. No ancillary bits, no padding, nothing at all. End of audio data, end of bitstream.
(Which, as a normal user, I take as reasonable.)
This DOES NOT MEAN that any last uncomplete frame has valid data! It may.
The actual approach of analysis is to evaluate the size of the last frame and discard it whether it appears as uncomplete, but - as I always knew - this is not the right thing to do. Such a frame may contain valid data and (when it does) it deserves to be included in global analysis.
The point with mp3guessenc is that any single frame is taken as valid and analysed through a number of functions, and a lot of data are extracted in order to add them to the global stream statistics. What now, with this new uncomplete frame?
Should I assume it as valid and take any data I need as I do with other frames, eventually discarding those data when it appears to be broken in fact? Nope.
Should I assume it as broken and discard any data it may contain? Nope.
Should I assume it as uncertain? Should I take any data I need as I do with other frames, eventually acknowledging those data only at the end of analysis, when it appears to be valid? Yes, I should.
At this point, a big change is required.
If mp3guessenc will be able to gather all the informations about a frame and keep them apart from the global results, then final analysis will tell whether to keep those results or discard them. Doing that, when a frame is proven valid, then its data may be merged with the rest.
So, any function will have to analyse the current frame and put any data into a small data structure which will be acknowledged at the end. (the actual behavoiur is to put any new informations into the global statistics data structures as soon as possible)
Big changes, big amount of bugs. I hope I'm wrong.

At last, beta time is up!
And now, after little tiny changes, the long way is at its final destination.
Enjoy the "Farewell" release!

Last stop before the final stable release, this beta2 is now available for everyone to download.
What are you waiting for?
Get it, build it, test it, enjoy it!
LIST GAMES!

Suddenly, I wondered whether mp3guessenc could run in a plain 16 bit DOS environment and I thought: "I think it does. Let's prove it!"

It took a half a hour to set up a virtual machine (in vmware player) with a fresh new FreeDOS v1.1 system (hey, their installer has gained completeness and simplicity since the last release I tried years ago!); I downloaded any zip archive listed in the zip-picker for DJGPP (which, btw, is a great tool for lazy guys like me) and my build environment got ready.... read more

This is a little modified version which adds no new features but Haiku compatibility! Haiku Powered Re-release of mp3guessenc can now build and run under Haiku R1alpha3. Sooo nice :-)
No feature added, so win32 binaries are still the same.

This release shows less warnings during analysis, while offering more compatibiliy with layer III streams.