Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Opinion on file quality (Read 4482 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Opinion on file quality

I just had a quick question for you guys (or girls). I recently downloaded some songs of the net and according to encspot they are encoded with either Blade or Lame old/m3e. Now I'm making the assumption that generaly theses files would suck, but the're encoded at 320k with simple stereo. Any comments about the quality of these encodes?

Thanks:D
I\'d rather be forgotten, then to be remembered for giving in

Opinion on file quality

Reply #1 –
1) Somebody needs to get a new encoder

2) 320 is overkill for lossy. Might as well go lossless.

3) If you're happy with them (sound/size), then fine. If you're not, then get some others.

Opinion on file quality

Reply #2 –
Hi. I have many such files. They sound quite good to me:D  I am pretty leary though of 320 files, especially blade, because many of them seem to be transcoded from lower bitrate files.

For instance, more than a handful had a 16khz cut off and were full of flanging. Blade is a lesser encoder, but it is not shit at 320.

If they really bug you, sit down with win mx and encspot and start hunting for better files. With rare stuff, I am usually really happy to get an old Lame or blade@320 file.

Opinion on file quality

Reply #3 –
Yeah.  A lot of people think by re-encoding a 128kbps to 320kbps it will sound better.  When I search with WinMX stuff, keep EncSpot open so you can spot the encoder before the downloads gets too far.

Also, I noticed picking out some of the files with Bitrates around 192, but not at gets usualy LAME VBR (preset) files.

Opinion on file quality

Reply #4 –
Quote
Originally posted by kennedyb4
Blade is a lesser encoder, but it is not shit at 320.
Far from it. Blade actually does pretty damn well with a small range of music such as acoustic guitar, as long as you're encoding at 192kbps or higher.

Opinion on file quality

Reply #5 –
Quote
Originally posted by NeoRenegade
Blade actually does pretty damn well with a small range of music such as acoustic guitar, as long as you're encoding at 192kbps or higher.
Not true. Blade introduces pre-echo with sharp guitar string sounds. Also in general 192kbps Blade sounds horrible.
Maybe you've taken too seriously those claims by Tord about Blade's "tonal purity"..?
Juha Laaksonheimo

Opinion on file quality

Reply #6 –
BladeEnc is based on the ISO encoder, just like lame 1.0 back in 1998 .....

Opinion on file quality

Reply #7 –
Oh well, then maybe I should go back to my original opinion that Tord's a wanker.

You know, I found out through an e-mail discussion with the poor guy that he actually believes the BS he tells people…

Opinion on file quality

Reply #8 –
I'm not going to debate the usefulness of the Lame TAG but want to ask one question:

In Encspot a file encoded with --r3mix w/ Lame 3.88 beta is given a Quality Index of 88, one encoded with --alt-preset standard gets a 78? Did I miss something (I probably did) and should I attach any value to this information (I know I know - first trust your ears !)
No inspiration

Opinion on file quality

Reply #9 –
Quote
Originally posted by YinYang
2) 320 is overkill for lossy. Might as well go lossless.

I recently found a use for --alt-preset insane: Encoding vinyl rips of old Moog synth records.  Combine some pretty complex electronic noises with the unpredictability of vinyl (including the clicks & pops of course), and... insane sounds better to me than extreme, although I didn't ABX.

Opinion on file quality

Reply #10 –
deej_1977: Yeah, I've noticed that too. Xing (new) encoded files (VBR) get 100. I guess that higher is worse?

Opinion on file quality

Reply #11 –
Quote
Originally posted by deej_1977
.. the Lame TAG but ...
In Encspot a file encoded with --r3mix w/ Lame 3.88 beta is given a Quality Index of 88, one encoded with --alt-preset standard gets a 78?

I might be missing something too
In LAME 3.88 the LAME tag and also --alt-preset were not finished. Is this an EnSpot Pro feature to add these Quality figures?
--
Ge Someone - EncSpot Basic user
In theory, there is no difference between theory and practice. In practice there is.
 

Opinion on file quality

Reply #12 –
Quote
Originally posted by deej_1977
I'm not going to debate the usefulness of the Lame TAG but want to ask one question:

In Encspot a file encoded with --r3mix w/ Lame 3.88 beta is given a Quality Index of 88, one encoded with --alt-preset standard gets a 78? Did I miss something (I probably did) and should I attach any value to this information (I know I know - first trust your ears !)


This is one of the very reasons why the LAME tag is right now, in my opinion, pretty much useless.  It's also a big reason why these sorts of quality values or "optimal/non-optimal" bits shouldn't be used.

The information in the LAME tag, as stated correctly by GeSomeone, is outdated.  It does not take into account any of the code level modifications used with the --alt-presets because it doesn't know how.  The inflexibility of the spec used for the current LAME tag, also makes it fairly unlikely that this will change in the future either.  To add insult to injury, the LAME tag has no concept of nspsytune2 either, or the non-linear psymodel, etc, etc, etc.

What we really need is an entirely different system.  In my opinion, an optimal system would work as follows:



    Will a system like this ever be present in LAME?  Who knows... it would actually take a little bit of work at first to build a lookup table, but it shouldn't really be that difficult.  The main problem is convincing the LAME developers that the current tag is not optimal and that a different system should be used (and then actually getting them interested in implementing it )...