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: best mp3 encoder with something better than a command line interface? (Read 33833 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: best mp3 encoder with something better than a command line interface?

Reply #50
Quote
ABX Results:
E:\abchr-java-0.5b\abchr-java\MyEnc.mp3 vs E:\abchr-java-0.5b\abchr-java\DefaultEnc.mp3

Do I understand correctly that you did the test wrong for the third time?
Both samples have same bitrate

DefaultEnc.mp3    = mp3, 320 kbps, 44100 Hz, 2 channels, encoded with LAME default settings:
                      lame --preset insane --verbose original.wav DefaultEnc.mp3
                                using ATH type 4 with default psy tuning settings

MyEnc.mp3   = mp3, 320 kbps, 44100 Hz, 2 channels, encoded with extended LAME settings:
                      lame.exe -ms --ns-bass -8 --ns-alto -8 --ns-treble -8 --ns-sfb21 -16 --interch 0.0002 --verbose -V0 -b256 -B320 -F --lowpass -1 --highpass 0.001 original.wav MyEnc.mp3
                                using ATH type 5 with minimal/(or none?) psy tuning settings

What's wrong?

Re: best mp3 encoder with something better than a command line interface?

Reply #51
I see you've moved from using CBR (in the first page of this thread) to using VBR with a constrained minimum bitrate so that it doesn't go lower than 256.

That simple thing is, in fact, making the encoder work with a different engine and it is, by itself alone, known to produce different results than the CBR engine.

Also, if I understand it correctly, what you are doing with that usage of the -ns-xxx settings is to increase the margin in dBs of adjacent frequencies before considering that it is masked by the stronger of both. As such, that tells the encoder to take more part of the signal as important.
The problem is... what will the encoder do when it doesn't have enough bits? Since you're making everything important, you might be pushing it to cause dropouts, a much more annoying problem.

Btw.. the "--interch" setting currently does nothing. You simply have to check the code searching for "interch". You'll see where it is read from the console, where it is defined in the presets, where it is set to the engine and... where it is completely ignore right now by the engine.
The documentation in html also says:
Quote
--interch x     Currently unused

Re: best mp3 encoder with something better than a command line interface?

Reply #52
What's wrong?

You took two MP3 files and did an ABX of them.  That isn't useful, it just tells you that you can hear a difference between the two MP3 files, but you don't care about that. 

You said you were trying to figure out which settings are better for that one specific sample.  Is that still the case?  Then you need to do the test suggested here:

https://hydrogenaud.io/index.php/topic,116217.msg963803.html#msg963803

I suggest doing them in order too, since if the first fails the second will fail too. 

Re: best mp3 encoder with something better than a command line interface?

Reply #53
What's wrong?

Example:
You have your lossless source, let's assume it's music.flac.

You take that file and encode it twice, once with the default settings (let's call that one default.mp3), and once with your settings you wanna prove are better (call that one custom.mp3).

Now you do two ABX tests:
  • music.flac vs. default.mp3
  • music.flac vs. custom.mp3
Now those results would be significant.

What you did instead, was ABX-ing default.mp3 vs. custom.mp3. Your result just means there is some difference between those files, which you find to be subjectively preferable over the other. It doesn't prove your settings are in any way better (or worse) than the defaults.

Re: best mp3 encoder with something better than a command line interface?

Reply #54
Ok, being another Professor Frink claiming you found a new approach to how LAME can be "improved" - (sigh!) via spectral analysis - is kinda part of life in this community - I'd go as far as saying there is a steady annual provision of those (usually new) members!

But, throwing out of the windows the 20+ years of know-how its developers (as well other members here) have put into it and completely ignoring the great advice that's being generously given to you is just plain childish pigheadedness!
Listen to the music, not the media it's on.
União e reconstrução

Re: best mp3 encoder with something better than a command line interface?

Reply #55
Ok, being another Professor Frink claiming you found a new approach to how LAME can be "improved" - (sigh!) via spectral analysis - is kinda part of life in this community - I'd go as far as saying there is a steady annual provision of those (usually new) members!

But, throwing out of the windows the 20+ years of know-how its developers (as well other members here) have put into it and completely ignoring the great advice that's being generously given to you is just plain childish pigheadedness!

We should convert the bits of images/photos to audio, and then compress them acoustically. /rant