I have a question about short fft analysis window positon.
In mp3, the long fft will be 1024 points, short will be 256 points. In the ISO doc, the short fft will at
:|......256.....|...128...|...128...|...128...|...128...|.....256.....|
...................|..... block 0 ..... | ..... block 2 ..... |
................................|..... block 1 ..... |
but in lame it looks like this
:|......256.....|...128...|...128...|...128...|...128...|.....256.....|
|....192...|..... block 0 .....|..........|...... block 2.....|...192....|
.................................|..... block 1 ..... |
I dont know why lame change it? Any LAME developer can reply?
Thanks in advance.
Full Version: Short FFT position?
From what I have seen there is very little work done on this type of work lately. Many developers contributed to the work of lame. So why certain things were done have often been forgotten or long since lost.
Today you will be lucky if a lame developer does more than arbitrarily assign a preset to a built in switch. That way when you try to test the engine of your encoder with different settings you get nothing but the presets the developer thinks you are smart enough to use.
How do you know if their fft routine is better? Since there is no way to switch between routines (iso, or lame) or any way to change many of your settings in lame. (In more recent versions) It is best that either you trust that the developer made the best choice or select an encoder version that does. (Read:3.90.2) Or an encoder that has a development community instead of regime (Read:Vorbis)
Brian
Today you will be lucky if a lame developer does more than arbitrarily assign a preset to a built in switch. That way when you try to test the engine of your encoder with different settings you get nothing but the presets the developer thinks you are smart enough to use.
How do you know if their fft routine is better? Since there is no way to switch between routines (iso, or lame) or any way to change many of your settings in lame. (In more recent versions) It is best that either you trust that the developer made the best choice or select an encoder version that does. (Read:3.90.2) Or an encoder that has a development community instead of regime (Read:Vorbis)
Brian
QUOTE
In mp3, the long fft will be 1024 points, short will be 256 points. In the ISO doc, the short fft will at
...
but in lame it looks like this
...
...
but in lame it looks like this
...
I am not sure to understand your question. I think that in Lame the analysis window positions are the same as in the ISO example.
If you are asking why when using short windows analysis block 0 is not contiguous to block 2, this is normal.
A short window is 192 samples. If you apply a 256 samples analysis window centered over it, you have 32 "extra" samples on each side. With only 32 samples, analysis of blocks 0 and 2 can not be contiguous.
I think that the second post is deserving a specific response.
Not sure if things have really been forgotten, but you are right in the fact the more documentation regarding the inner engine would be very nice.
Unfortunately:
a) it takes time
b) it is sometimes hard/tedious to properly explain things in a language that is not your native one.
Facts please. Which lame developper arbitrarily assigned a preset to a built in switch? Are you also implying that Lame developpers are only doing this?
You have to know that Lame is not yet smart enough to be able to auto-generate itself. If something is inside, it is because developpers put it inside. And guess what? Some developpers are still there, 5 years after, to work on it.
ISO doesn't defines mp3 encoders, but only decoders. They are providing an example of encoder, not a rule.
Which settings are you unable to change?
3.96 is not making the best choices? Which ones please?
A regime?? What do you mean there? What do you prefer in Vorbis development compared to Lame?
QUOTE
So why certain things were done have often been forgotten or long since lost.
Not sure if things have really been forgotten, but you are right in the fact the more documentation regarding the inner engine would be very nice.
Unfortunately:
a) it takes time
b) it is sometimes hard/tedious to properly explain things in a language that is not your native one.
QUOTE
Today you will be lucky if a lame developer does more than arbitrarily assign a preset to a built in switch
Facts please. Which lame developper arbitrarily assigned a preset to a built in switch? Are you also implying that Lame developpers are only doing this?
You have to know that Lame is not yet smart enough to be able to auto-generate itself. If something is inside, it is because developpers put it inside. And guess what? Some developpers are still there, 5 years after, to work on it.
QUOTE
Since there is no way to switch between routines (iso, or lame) or any way to change many of your settings in lame. (In more recent versions)
ISO doesn't defines mp3 encoders, but only decoders. They are providing an example of encoder, not a rule.
Which settings are you unable to change?
QUOTE
It is best that either you trust that the developer made the best choice or select an encoder version that does. (Read:3.90.2)
3.96 is not making the best choices? Which ones please?
QUOTE
Or an encoder that has a development community instead of regime (Read:Vorbis)
A regime?? What do you mean there? What do you prefer in Vorbis development compared to Lame?
1. Of course it takes time and there has been developement on documentation in recent months.
2. I am speaking most directly about assigning presets to the switches of -V
No, it is not only Lame developers doing this. Lame has had a long legacy of being able to 'tweak' now while this caused occassionally poor music for download, It really didn't hurt anyone that was legitamatly archiving. If it didn't sound bad to them it was o.k. to have a poor command line because it was transparent. Allowing people to select vbr quality modes is important specifically because you can't get down and test the nitty gritty.
3. I should clarify. As far as fft Lame only has its routine not ISO it is my understanding this was not for patent issue. Not a problem.
4. I disagree strongly with mapping presets to anything but presets. They should not now nor ever be mapped to -V. --preset standard is easy enough to type.
5. I like that vorbis doesn't cut the throat of anyone trying to develope their open source software. I have seen much drama relating to developement and because someone didn't like how they did things they no longer allowed cvs access. Even for branching. e.g. Frank Klemm
6. I do appreciate your efforts in what I like to call PR. Public Relations. You answer questions about developement, run listening tests and interact with the community. It is very useful and needed.
7. Put the presets back to presets and let the -v be -v. It works it doesn't need to be fixed. It doesn't make things better by doing it this way.
Lossy
2. I am speaking most directly about assigning presets to the switches of -V
No, it is not only Lame developers doing this. Lame has had a long legacy of being able to 'tweak' now while this caused occassionally poor music for download, It really didn't hurt anyone that was legitamatly archiving. If it didn't sound bad to them it was o.k. to have a poor command line because it was transparent. Allowing people to select vbr quality modes is important specifically because you can't get down and test the nitty gritty.
3. I should clarify. As far as fft Lame only has its routine not ISO it is my understanding this was not for patent issue. Not a problem.
4. I disagree strongly with mapping presets to anything but presets. They should not now nor ever be mapped to -V. --preset standard is easy enough to type.
5. I like that vorbis doesn't cut the throat of anyone trying to develope their open source software. I have seen much drama relating to developement and because someone didn't like how they did things they no longer allowed cvs access. Even for branching. e.g. Frank Klemm
6. I do appreciate your efforts in what I like to call PR. Public Relations. You answer questions about developement, run listening tests and interact with the community. It is very useful and needed.
7. Put the presets back to presets and let the -v be -v. It works it doesn't need to be fixed. It doesn't make things better by doing it this way.
Lossy
QUOTE
I am speaking most directly about assigning presets to the switches of -V
Presets have not simply been assigned to -V. It is mostly the reverse. Presets are now used by default, and have been extended down to -V9.
And the actual work was much more than a simple switch assignement.
QUOTE
As far as fft Lame only has its routine not ISO it is my understanding this was not for patent issue
Lame doesn't have any code from the ISO demonstration code anymore since now 4 years.
QUOTE
I disagree strongly with mapping presets to anything but presets
Presets are not mapped to anything but presets. It is just that vbr presets are now the same thing as -V values.
CODE
I like that vorbis doesn't cut the throat of anyone trying to develope their open source software. I have seen much drama relating to developement and because someone didn't like how they did things they no longer allowed cvs access.
Anyone is free to work on Lame and create its own version if needed.
Do you know how many people have cvs access to Vorbis?
QUOTE(LordofStars @ May 27 2004, 06:16 PM)
5. I like that vorbis doesn't cut the throat of anyone trying to develope their open source software. I have seen much drama relating to developement and because someone didn't like how they did things they no longer allowed cvs access. Even for branching. e.g. Frank Klemm
Well, at least they gave CVS access to Klemm once. And, knowing Frank's very bad social skills, I can understand why they removed it at some point.
Xiph never gave CVS access to anyone outside their little group.
I disagree with the vbr PRESETS being assigned to the -v value.
I also agree with having an overall cvs mod. They do accept and review contributions.
From what I have seen Lame has in the past limited contributions. Currently they have no one overseeing the project and changes are made with very little testing.
I know that ISO code has been removed for over 4 years. This is not a problem it was done because of patent issues.
Brian
I also agree with having an overall cvs mod. They do accept and review contributions.
From what I have seen Lame has in the past limited contributions. Currently they have no one overseeing the project and changes are made with very little testing.
I know that ISO code has been removed for over 4 years. This is not a problem it was done because of patent issues.
Brian
QUOTE
Currently they have no one overseeing the project and changes are made with very little testing.
If you think that our current testing is not enough, please suggest some other tests
The current way is using some encode/decode tests directed by some python scripts. They are testing more than 200 combination of options.
QUOTE
I know that ISO code has been removed for over 4 years. This is not a problem it was done because of patent issues.
It has nothing to do with patent issues. Source code can not be patented, but only copyrighted.
QUOTE(LordofStars @ May 27 2004, 08:37 PM)
This is not a problem it was done because of patent issues.
Perhaps my choice of words is not correct. Patent and copyright are interchangeable in my vocabulary. I know they aren't but that is how I speak.
seems I have to response to this question. but I have no time... see the detailed comments in the psymodel.c and lame.c of my experimental branch (aka LAME4 branch).
That's the answer.
To make things more shortly, "that's a bug of ISO code"
That's the answer.
To make things more shortly, "that's a bug of ISO code"
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.