192 kbps

Topic: 192 kbps (Read 10671 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Reply #25 – 2001-12-31 08:40:03

Quote

Originally posted by wildboar
"the scene" is poisoned by the misinformation spread by alt.binaries.sounds.mp3.d and their FAQ that hasn't been updated since 1923.

Take for instance:

You can read more of this little gem at:
http://www.mp3-faq.org/

So make sure you keep everything encoded with the latest release of Blade at 192 stereo (oooh the purity!!) to prevent that horrible "flanging" presented by the evil joint-stereo. :eek:

hahahaha!!!!!!

192 kbps

Reply #26 – 2001-12-31 09:09:37

I just participated in C.H.C.'s latest blind test, which pitted blade 0.927, the FhG Alternate codec in MMJB 6.1, and lame 3.90 alpha 8 at CBR bitrates from 160 to 224.

What I heard was that Blade was awful at both 160 and 192, and I could still hear that it was worse at 224 than FhG at 160!

Here was my post in alt.binaries.sounds.mp3.d

Quote

Someone posted:

>Can you actually tell the difference between a good 160k encoding and
>224k? I can't. Very few people can in a genuine blind trial. If you
>think you're one of the few, please try this simple test and prove it:
> http://www.imnsho.com/challenge.htm

Here are my results, without revealing which number corresponded to what encoder:

I completed all comments before unzipping the answer key, and substituted in the actual encoders for this post. The ordering of the encoders below is not the same ordering as the sample numbers.

Chose mmjb160 as the provisional original

blade160: I guess Blade at 160?; transients smeared; background noise (ABX 16/16)
blade192: transient smearing; another 160 encode? As bad as blade160
blade224: slight noise on the first "pop" (ABX 14/16 compared with mmjb160)
lame160: puff of noise with first "pop" (ABX 15/16 compared with mmjb160)
lame192: ok
lame224: ok
mmjb160: ok
mmjb192: ok
mmjb224: ok
orig: ok; maybe slightly quieter on the "pops" than mmjb160 and lame192.

This sample was easier than the last sample I listened to by C.H.C. At least here I'm able to hear Blade's flaws pretty clearly. Looks like mmjb is the clear winner for 160 kbit/s encodes, at least compared to the lame cbr setting chosen. At 192 and 224, both mmjb and lame are fine to my ears.

ff123

192 kbps

Reply #27 – 2001-12-31 10:47:53

trying to convince those "blade blinded" gurus is senseless heh ?

192 kbps

Reply #28 – 2001-12-31 15:37:36

Quote

First of all, the RioVolt does play VBR/ABR files, but support for them still feels rather sketchy. Meaning I get audio, but may or may not be able to seek properly within the file, etcetera.

Well, that's not true.
I've been using the player for 10 months now, with VBR, and it works great, including seeking 1x 2x 4x, the remain time is displayed correctly, and you can also seek within a file starting from its end (yes! by playing first few seconds of a file next to the desired file and holding the RW key) but you must follow certain rules. I have to mention that the sound quality is astonishing.

I don't have time to experiment more. The facts are:
1. if a file doesn't have any ID3 - seeking works perfectly
2. if a file has ID3v1 ONLY - seeking works perfectly
3. if a file has ID3v2 ONLY - something's wrong: the remain time is totally wrong and seeking is unpredictable

Did you try adding both ID3v1 and ID3v2? Should be working then.

It must be an easy-to-remove bug, because it seems that the player is generally capable if seeking within a VBR mp3. Thank god, the unit is firmware-upgradable. I think they're gonna fix it and release an upgrade.

Anyway, I don't use ID3 at all, because the player displays them like this :
"[title] - [performer]"
and it scrolls this long line and I don't have the patience to wait until it displays [title].
If there's no ID3 - the player displays filename, which may be [title] only. In my opinion this is more convenient.

Oh, I have to mention that I have AVC Soulplayer, not RioVolt, but you probably know that these are exactly the same units, because Rio corp. bought the license from AVC corp. and they have only changed the case. Soul and Volt are the same machines inside. The firmware may vary, though, so you probably have to experiment with ID3 yourself.

But as I said, if you follow certain rules, the player works perfectly with VBR.

Hope this helps.
Olcios

192 kbps

Reply #29 – 2001-12-31 15:43:52

Quote

Originally posted by M
"--nogap" denotes gapless encoding for a set of contiguous files (that is, files sent sequentially through the encoder). How long has this been in LAME? I've been told Blade already had something like this, but I had not read anything about LAME implementing it.

Yes, BladeEnc has it for sometime now, but in Lame it's only half-backed at the moment. Last time I tried (3.90 alpha6) the VBR-header, that most players rely on for bitrate indication and seeking, was only present in the last file of the gapless sequence.

Quote

This means - if it works properly - that I no longer need to encode an album as a single stream and split it; also, in RazorLame I should be able to visually arrange the files in their proper encoding sequence and they will *automatically* be gapless!

Apparently one also must include the "--nogapout" switch to redirect gapless output to the proper path. I tried using RazorLame's internal redirect, and the files still wound up in the source directory. Is this a bug, or simply a necessary part of the gapless encoding mechanism?

Well, RazorLame doesn't support -nogap at all. It starts the lame process separately for each file to encode.
-nogap (as it is in the current state) needs the files, that must gaplessly encoded, together on one command line (though wildcards can be used also, if I remember correctly).
--nogapout is needed because of the different input syntax.

Hope this clears something up a bit.
--
Ge Someone

Notice