does anyone knows some info about this mp3 encoder that I found when looking at a mp3 file in encspot

I believe Gabriel has some info here: http://www.mp3-tech.org/

Encspot? Did someone ever encode anything with shine???

Shine is "a very minimalist" MP3 encoder - it implements the absolutely basic to create compliant bitstreams.

AFAIK, it's not tuned at all, and I expect that even the quality of dist10 is superior.

Besides, I never heard of a windows compile.

I know of one file in the universe encoded with Shine, which is this one.

I saw the Kill Bill soundtrack encoded with shine that I took in a P2P. I only took 2 files the others I found with lame 3.93 B) but that encoder seemed intriguing to me ... . The quality seemed very decent to me.

Seemed quite acceptable to me as well. I've heard much worse.

I wonder if somebody has been running Shine on an Acorn-RiscOS (the only platform Shine was compiled for as far as I know) emulator to encode the Kill Bill soundtrack. And if so, WHY?? .

My best guess is that Encspot's wrong here. The files are encoded with 100 % long blocks and dual-channel. Any ideas?

Shine has a quite bad quality. The goal was only to simplify things in order to achieve a better comprehension of the process. (however, I am not sure if it's worst than dist10 overall)

I would advise you not to encode with it if your final goal is listening to the tracks.
There is a case where Shine is likely to be used: ARM-based computers. On those slow computers, Shine is a lot faster than most other encoders because it has been ported to fixed point code.

My best guess is that EncSpot is right.

I confirm that the encoded files that I found are 100% long blocks and dual channel, so it´s almost sure they where encoded using Shine.

I'm not sure that's Shine-encoded. Sure EncSpot reports it as Shine, but it also reports some other weird stuff (that it's a layer-2 file, for example). The ID3v2 tag mentions iTunes v4.0.1 (which may or may not be accurate, but I suspect it might be). Note from the following screenshots how the reported information varies (notably sample frequency) as EncSpot scans through 2000 frames, then 4000 (6000 is identical to 4000), and finally the full file:


I don't know what did encode that file, but I don't believe what EncSpot is telling me. I don't see anything obviously wrong with the file that would cause EncSpot to go crazy like that. It's a CBR 128kbps file, with 7561 (a slightly different count than EncSpot reports) 128kbps joint-stereo frames.