I have used a program called MP3 Splitter Joiner for quite some time and just recently noticed the encoder change (LAME to Blade) after the files have been split. MP3 Splitter Joiner must perform some sort of MP3 encoder ID stamping without any actual conversion to the file itself (no real transcoding is occuring-determined by the amount of time it takes to split and save the split files). I was looking at the ramifications of changing the encoder from the versatile LAME to the unknown Blade (the only thing I have found about Blade is that LAME should be used instead of Blade - Scott Hacker's MP3: Definitive Guide).

What is telling you that it is now encoded with Blade?

I am using a program called MP3 Book Helper that identifies the Encoder (LAME, Blade, etc.) and Encoder type (MPEG 1 or 2 along with layer information).

I highly recommend everyone, to not use Blade at all costs. Avoid Blade like the plague.

That is in line with Scott Hacker's MP3: The Definitive Guide. It appears (based on processing time) that MP3 Splitter Joiner simply uses Blade to process the splitting and joining of an MP3 file. It is not actually transcoding the file. I have a 17 hour MP3 that I split up into 1 hour segments and MP3 Splitter Joiner performs the process in the same amount of time it would take to save the resulting files (or copy the single 17 hour MP3 file to another location). If it were transcoding, that would at least double the time it took to process this 17 hour MP3 file. Of course, I am making an assumption that no transcoding is going on that may be wrong, but by observing the amount of time MP3 Splitter Joiner is taking, this leads me to conclude that this is a correct assumption.

MP3 Book Helper (and other programs, e.g. Encspot) cannot reliably identify MP3 encoder, so information it gives can be wrong.

Based on processing times, my best guestimate was in line with this statement. The splitter program simply "stamped" the Blade ID on the encoder field in the metadata. This would mislead programs like Encspot into giving us bad information. How would I change this field to revert back to the actual encoder used?

That's basically correct, however there is no universal "encoder field" to be "stamped". If there was then programs like encspot would be far more straight forward and 100% reliable (which they are not). Programs like encspot largely just guess the encoder based on the information contained in the mp3 header. While it's true that the header may contain specific information about the actual encoder and version which was used, in many other cases it might not and then encspot is only really guessing.

The bottom line is that mp3joiner has most likely stripped out some of the header information (without effecting the actual mp3 data) and now the program can not longer correctly identify the original encoder. Be aware that these programs are not 100% accurate at guessing the encoder, the mp3 encoders are often incorrectly identified.

Why?

Do you not like the guy who wrote it?

Did you screw up all your audio files with it?

Give us a reason why, otherwise you will just be ignored.

I have been using Blade Encoder for years and it gives me as good quality as LAME or better, with a bit more control over the encoding process, better multi-threading and works from the command line.

@ Mistoffeles

I doubt that Blade gives "a bit more control over the encoding process, better multi-threading". (And of course, LAME works from the commandline too)
http://wiki.hydrogenaudio.org/index.php?title=Blade
http://lame.cvs.sourceforge.net/*checkout*/lame/lame/USAGE


And since you ask, here there is one of the reasons why Blade should not be used nowadays:

http://www.rjamorim.com/test/128extension/results.html

Hmmm let's see:

It's very basic.
Lacks joint stereo.
No block detection.
No low-pass filter.
It's crap at using the bit resveriour.
Lacks VBR support (it would suck at it anyway).
Produces precho artifacts all over the place.
It just cries for a good tuning.
Sounds really crap even at 320kbps.

It's that bad i could ABX a Blade mp3 with my crappy PC speakers.

Basic is good, I don't need featuritis, that's why I use OpenOffice instead of the bloated MS Office, and so on. There are so many useless (to me) extra features in LAME that only produce a slightly (if at all) noticeable difference in the sound, as in about as much difference as a vinyl LP played on two different (but excellent) turntables (and yes I can hear the difference between records played on a Micro Seiki DQX-500 and a Kuzma Stabi XL most of the time, all other things being equal).

Joint stereo is not as good as true stereo, where both channels are encoded independently. All joint stereo does is make your files a little smaller, not something I need since I have terabytes of hard drive space and a 16GB iTouch.

Block detection is meaningless.

Low-pass filter is also meaningless with decent equipment (i.e.: better than "crappy PC speakers"), a good original recording and a quality audio ripper.

VBR would be nice but again I have no use for it, and your opinion that "it would suck anyway" is just that, opinion.

I have encoded thousands of tracks using Blade over the past several years and have never had an issue with the quality at 192, 256 or 320k, even with my less than stellar Harman-Kardon speaker system. I've tried LAME many times since I started using Blade and it really does not do much for me, except load up with more and more options that I don't need with every release.

But...at least you made an effort to back up your statement, however horridly typed, which is an improvement <golf clap>.

Oh great, a yet another user at Hydrogenaudio that thinks Joint Stereo is the devil.



Block detection and what type of block to use dose matter on alot sounds that have sharp transients, such as castanets and eig.



Judging from how crappy Blade is at mid and low bitrates (below 256) and how immature VBR was on Fhg and LAME at the time when Blade was in development, it would suck at VBR big time IMO.



Jeez, you don't have to be asshole about it.

But seriously Blade performs really badly below 256kbps. While only 256 - 320 produces slightly acceptable quality, but still far from being transparent.

A few examples:



Very easy to ABX at 320kbps. There is heavy drum smearing and disortion at the start.



ABXable at 320kbps. Smearing all the over place at the start and warbling at 0:02.5.

Mistoffeles, I notice you didn't comment on the rather damning evidence that [JAZ] provided.
http://www.rjamorim.com/test/128extension/results.html

C.

He probably doesn't care how bad it is at 128 kbps since he apparently only uses 192 kbps and up. He is also apparently unwilling to extrapolate.