ffdshow tryouts project: Discussion & Development [Archive] - Page 95

madshi

22nd October 2008, 17:22

from the specs :
If progressive_frame is set to 0 it indicates that the two fields of the frame are interlaced fields in which an interval of time of the field period exists between (corresponding spatial samples) of the two fields.
If progressive_frame is set to 1 it indicates that the two fields (of the frame) are actually from the same time instant as one another.

I interpret like that :
progressive_flag==1 => progressive (same timestamp for both field => frame)
progressive_flag==0 => interlaced (two timestamps, one for each field)
Yes, that's what the spec says. And that's how it's supposed to be. If all DVDs were authored correctly, we could rely on "progressive_flag". No DVD player would then need an expensive video processing chip for deinterlacing because it could simply read out the flags and everything would be fine. The problem is that not all DVDs are authored correctly. You can not fully trust these flags because some DVD encodes are plain broken. That's why every good standalone DVD player converts all DVDs to 480i60 first and only afterwards uses expensive video processing chips (e.g. HQV Reon) to perform IVTC.

Having a deinterlacing mode which strictly makes use of the MPEG2 bitstream flags is not a bad idea. It will probably work well with many DVDs - but not with all. So it must still be possible to output any MPEG2 stream (except those with progressive_sequence set to 1) to 50i/60i.

Mercury_22

22nd October 2008, 17:33

Try this version of the assembly ffdshow 2239 x64 (http://www.xvidvideo.ru/component/option,com_docman/task,doc_details/gid,564/Itemid,11/) (libavformat branch (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,564/Itemid,11/))

NO SOUND ! :helpful: ON AC3; E-AC3; or DTS with libav ! Tested with MPC-HC & WMP 64-bit
Also your MPC 845 x64 Without installer 2008-10-22 18:28:39 2.64 Mb (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,559/) it's still 1.1.844.0 x64 (maybe just in about box):thanks:

SeeMoreDigital

22nd October 2008, 18:12

Yes, that's what the spec says. And that's how it's supposed to be. If all DVDs were authored correctly, we could rely on "progressive_flag"...

Having a deinterlacing mode which strictly makes use of the MPEG2 bitstream flags is not a bad idea. It will probably work well with many DVDs - but not with all. So it must still be possible to output any MPEG2 stream (except those with progressive_sequence set to 1) to 50i/60i.For those of us who back-up and store our DVD's on hard-drives, having an application that could check and correct the flags within the .IFO files and the MPEG-2 bitstream (without having to de-mux, re-mux/re-author), would be really handy indeed.

Cheers

madshi

22nd October 2008, 18:20

For those of us who back-up and store our DVD's on hard-drives, having an application that could check and correct the flags within the .IFO files and the MPEG-2 bitstream (without having to de-mux, re-mux/re-author), would be really handy indeed.
That would be very hard to do. If the bitstream is interlaced and just the TFF/BFF flags are wrong, that would be possible to correct (but still very difficult). But if the wrong fields are actually encoded incorrectly as frames then there's no way to fix that without reencoding.

tal.aloni

23rd October 2008, 00:13

Hi Tal,
The file indeed contains version number, I'm aware of that fact, but as you've said, it isn't maintained properly (at the moment, rev. 2240 shows version no. 1.0.5.2184, as did all the revisions I can think of).
That is why I asked if an automated process might be possible when compiling the binaries from source.

I'm not aware of an automatic process that will allow us to do that, and it would be too hard to this manually (by modifying the source each time).

please note that you could always use

rundll32.exe ffdshow.ax,configure

to see the revision number. (which is stored at the registry, under HKLM\Software\GNU\ffdshow\revision)

I hope that's good enough,
Tal

Anima123

23rd October 2008, 09:13

I'm trying to import yadif from mplayer. It's a complicated work.
IVTC is also an wanted feature. I guess it's more complicated though.

Wow, that's really a very nice news to hear. Though yadif can be accessed via AviSynth, a domestic support by ffdshow, which should save a log of cpu load, has been expected by me and others for a long time. Really nice to see there's someone who is working on it.

tal.aloni

23rd October 2008, 11:48

Offtopic:
is there any software deinterlacing filter in ffdshow that can perform simple BOB, with no additional processing applied?
if so, what are the required settings?

if not, do you think it will be useful? Should I try to implement one?

Thanks,
Tal

albain

23rd October 2008, 13:49

Hi,

@haruhiko, clsid, xxl
I have created a patch to fix the following bugs on SSA subtitles.

SSA position tags {\pos(x,y)} not applied correctly
SSA subtitles : the horizontal and vertical position sliders settings (in subtitle section config) are now applied when there are no positions defined (no margins and no position tags). Until now the subtitles were displayed at the bottom of the screen
SSA subtitles positionning : until now the positions were applied basing on the input resolution of the subtitles filter, which is wrong when the resizing filter is enabled before the subtitles filter. Now a ratio is applied basing on (input movie res / input filter res). Actually the code was already written but the input dimensions of the movie were always zero
SSA subtitles positionning : fixed vertical & horizontal positionning when some parts of the subtitles came out of the screen

Here is the link of the patch :
http://damienbt.free.fr/SSAFix.diff

Please report if this works fine before I commit the files.

tal.aloni

23rd October 2008, 13:58

as far as regaining volume is concerned - what's the current speed it regains volume at?

it's 6% per second to be exact (defined in the code as 'MUL_STEP'), and I think it will be a very good choice to the vast majority of the users of this function, so I didn't bother with confusing them with a list of options.
If there's a strong demand, I may change my mind.

Tal

Inventive Software

23rd October 2008, 14:37

Anima123

23rd October 2008, 14:39

tetsuo55

23rd October 2008, 14:44

I have been wondering this for a very long time.
Now with all the sound-related changes i'm going to ask:

Is it possible to create a universal Replaygain (target overall volume 89DB). It should work like the mp3 version that finds an overall volume level based on the entire file.

Requirements would be:
-Should be able to handle all audio codecs supported by FFDshow
-The replaygain data can not be embeded(altoug we should be able to get it into MKV eventually)
-Because we have a lot of read only media FFdshow should be able to locally store a list of replaygain data, like the system to remember last position on DVD's.(The has should be strong enough to prevent collisions, powerdvd has a very bad system and resumes different disks(like seasons tv shows) from the last play position of the last disk)

haruhiko_yamagata

23rd October 2008, 14:54

haruhiko_yamagata

23rd October 2008, 15:04

Wow, that's really a very nice news to hear. Though yadif can be accessed via AviSynth, a domestic support by ffdshow, which should save a log of cpu load, has been expected by me and others for a long time. Really nice to see there's someone who is working on it.
Thank you for motivating me more. But don't expect too much about the performance boost.
I required ffmpeg-mt + Core2 Quad to play premiere-paff.ts (http://x264.nl/h.264.samples/force.php?file=././premiere-paff.ts) using ffdshow-yadif(0,-1).
And yes, it's working if you don't care a few bugs.
The picture is beautiful.

tal.aloni

23rd October 2008, 15:12

I have been wondering this for a very long time.
Now with all the sound-related changes i'm going to ask:

Is it possible to create a universal Replaygain?

I was wondering about it too,
I think that the one-pass norm recently implemented is your safest bet, after 10 min. of movie watching, you'll be in the comform zone.
(the only other way I would have it is storing the gain in the file name, but it's really not worth the extra effort, one-pass norm is definitely good enough)

Tal

tetsuo55

23rd October 2008, 15:32

I was wondering about it too,
I think that the one-pass norm recently implemented is your safest bet, after 10 min. of movie watching, you'll be in the comform zone.
(the only other way I would have it is storing the gain in the file name, but it's really not worth the extra effort, one-pass norm is definitely good enough)

Tal

The way i understand it is:

Normalization Limits sounds to 89DB, making sure the sound never goes over this limit, it does a similar thing for low sounds, The dynamic range is partially lost in the process

Replaygain Lowers or Heightens the complete file's DB level based on the percieved loudeness of the entire file, the target is usually 89DB, dynamic range is fully retained.
More info: http://en.wikipedia.org/wiki/Replay_Gain
Imho its definately worth the extra file (i store everything on HDD anyway), Once it's working it could be added to MKV.

adam777

23rd October 2008, 15:48

I'm not aware of an automatic process that will allow us to do that, and it would be too hard to this manually (by modifying the source each time).

please note that you could always use

rundll32.exe ffdshow.ax,configure

to see the revision number. (which is stored at the registry, under HKLM\Software\GNU\ffdshow\revision)

I hope that's good enough,
Tal

I think the registry key you supplied should be sufficient.
Thanks again, Tal :)

tal.aloni

23rd October 2008, 16:46

The way i understand it is:

Normalization Limits sounds to 89DB, making sure the sound never goes over this limit, it does a similar thing for low sounds, The dynamic range is partially lost in the process

Replaygain Lowers or Heightens the complete file's DB level based on the percieved loudeness of the entire file, the target is usually 89DB, dynamic range is fully retained.

You got it wrong:
Normalization applies a constant amplification to the entire track, usually, the highest value that will never cause the track to go over the limit (1/max), The dynamic range is fully retained.

Replaygain add a predefined gain to the entire track, which can be equal to or lower than (1/max). in that case The dynamic range is fully retained, otherwise, The dynamic range is partially lost in the process, and clipping will occur.

Tal

albain

23rd October 2008, 19:56

Please send me samples which you use for testing.

Sorry, I have discovered a bug.

I am fixing it and will PM you the patch + the sample files

tetsuo55

23rd October 2008, 19:59

You got it wrong:
Normalization applies a constant amplification to the entire track, usually, the highest value that will never cause the track to go over the limit (1/max), The dynamic range is fully retained.

Replaygain add a predefined gain to the entire track, which can be equal to or lower than (1/max). in that case The dynamic range is fully retained, otherwise, The dynamic range is partially lost in the process, and clipping will occur.

Tal

You're right, i was confusing normalization with DRC.

does the normalization scan the entire audio track to find the correct value or does it decide it on the fly for every XX frames? (To be clear, i want to use this in real-time during playback)

SCRATCHY

23rd October 2008, 20:30

would be great if you could add more potent headphones psychoacoustic algorithms :)

I find the Sonic Audio Decoder 4.2 very impressive when set to "headphones", it gives a terrific 3D sound.

also, is it possible to have less AA on the subs ? I find them a tad blurry..

tal.aloni

23rd October 2008, 22:09

does the normalization scan the entire audio track to find the correct value or does it decide it on the fly for every XX frames? (To be clear, i want to use this in real-time during playback)

it would be time consuming and annoying if a complete audio track scan will be performd before the playback begins,
the idea behind one-pass normalization, it to start with some level of amplification, and decrease it when needed. with each decrease, the probability and intensity of the next overflow will be smaller, and usually after a few minutes of playback, you'll get very close to the right value for the track.

if you care about staying as close as possible to the source, but still want to be able to switch to music playback after the movie without being forced to turn the volume dial all the way down on the amp, this is the method to use. (you also get less static noise from the amp as well).
this is the method I'm using.

Tal

tal.aloni

23rd October 2008, 22:40

I think Kernel Bob does what you're after, yesno?
Yes, Kernel Bob will do just simple bob if the threshold parameter is set to 0.

Thanks,
Tal

tetsuo55

24th October 2008, 13:49

it would be time consuming and annoying if a complete audio track scan will be performd before the playback begins,
the idea behind one-pass normalization, it to start with some level of amplification, and decrease it when needed. with each decrease, the probability and intensity of the next overflow will be smaller, and usually after a few minutes of playback, you'll get very close to the right value for the track.

if you care about staying as close as possible to the source, but still want to be able to switch to music playback after the movie without being forced to turn the volume dial all the way down on the amp, this is the method to use. (you also get less static noise from the amp as well).
this is the method I'm using.

Tal

thanks for the info, i will use the normalization until we can get real replaygain (i would just take some time to scan all the files in my folder and be done with it)
I have not used the normalization yet, is it possible to limit it to 89DB (my audio setup is configured for this limit)?

tal.aloni

24th October 2008, 14:17

I have not used the normalization yet, is it possible to limit it to 89DB (my audio setup is configured for this limit)?

I'm not familiar with the scale you mentioned (89db),
we're talking about PCM here, and the limit is 1.0f, or 0db.

Edit: if you're so meticulous about the correct amplification level,
just find the peak for each movie, and make a batch file that will update the registry before executing playback.
(HKCU\Software\GNU\ffdshow_audio\default\volume)

tetsuo55

24th October 2008, 15:32

audio is measured in frequencies and decibels(DB)

Please check this link, it explains how to calculate the replay gain value and even has lgpl sourcecode for a working replaygain scanner.

The DB part should become clear and hopefully you can use the information to update ffdshow normalization to DB instead of % (even if you don't add the replaygain functionality)

tal.aloni

24th October 2008, 17:50

hopefully you can use the information to update ffdshow normalization to DB instead of % (even if you don't add the replaygain functionality)
1. already happening, see "decible scales" checkbox on volume configuration page.

2. you're link is missing, but I did some more reading on replay-gain. I also tested mp3gain.
it might be useful for mp3 listening, (if used correctly to decrease volume and not to amplify it, especially over 1.0f / max).
but if used to amplify the track, above (1.0f / max), clipping will occur and/or Dynamic range will be decreased.

as far as adjusting an entire movie, I'd definitely prefer normalization, and one-pass norm is good enough.

3. I suggest you'll take the time to examine the existing functionality.

audio is measured in frequencies and decibels

true, but you can't extrapolate the recording volume in db or the playback volume in db from a PCM sound file.

p.s. considering the fact that 0.2f sine wave @ 440hz is measured by mp3gain as 89.4db, I'd say you're probably using the wrong value.

tetsuo55

24th October 2008, 18:09

1. I see it now, the value is 12DB by default(400%), what should i change it to have the max value be 89DB?

2.Oops, here is the link:
http://replaygain.hydrogenaudio.org/calculating_rg.html

Replaygain is usually used for decreasing values, as most recordings are way too loud and clip like crazy.
Replaygain aims at the following: Physoaccoustically same loudeness for all files while retaining dynamic range and preventing clipping (although settings can be changed that will destroy dynamic range and cause clipping)

the problem with regular normalization remains that it's not based on phyochoaccoustic loudness.

3. I want to but i am unsure of the db scale used, how can i make the db values represent a maximum limit of 89DB

at your PS. That sine wave could be phychoaccoustically softer sounding. DB values could then indeed be slightly higher. Replaygain also checks for clipping so if that value was to result in clipping it would lower it to the highest possible value that doesn't clip.

----------

Okay i tried the following using rev 2242
-Volume checked
-Master Volume 100%/0DB
-All channels 89%/-1DB
-Normalize and lower unchecked (to disable DRC)

---------

Okay i extracter the audio and let foobar scan the mp3gain value. it took about 1 minute for the full movie(1hr51min).
The values are:
Track Gain (dB): -12.550000
Track Peak(dB): 1.517128

I did a non-abx test, and i was unable to geusstimate a value that matched the replaygains output. ffdshow was always louder.

tal.aloni

24th October 2008, 18:51

I want to but i am unsure of the db scale used, how can i make the db values represent a maximum limit of 89DB

What the standard actually states is that a single channel pink noise signal, with an RMS energy level of -20 dB relative to a full scale sinusoid should be reproduced at 83 dB SPL

confirming mp3gain's report, you're precious 89db actually means maximum sound level of 0.2f (or -14db).
so the idea is to maximaize the signal to 100%, and attenuate 14db simultaneously:
set your master volume to -14db (20%),
and your "max amplification" to 12db (400%),
uncheck "Regain volume".

but this is not very wise, before you do that, I'd recommend leaving the master volume at 100%. I'm pretty sure this will work for you far better. there is no sense in limiting the computer volume output to 20%, especially over analog conection.

tetsuo55

24th October 2008, 20:49

Okay lets see if i understand this correctly

Set master volume to 20% (this limits the internal ffdshow processing to 89DB, no sound will every cross this boundry and no clipping will occur, at the same time dynamic range is maintained)

Normalize up to 400%, this will change the volume dynamically to make all scenes sound equally as loud, it will re-evaluate the loudness every few seconds to see if the amplifictation needs to be changed. Some dynamic range could be lost as quiet scenes are amplified more than loud ones.

Limit testing shows that this setup actually sounds somewhat ok

Setting the master volume back to 100% makes everything way too loud again.

I will try to explain how my audio is set up.

Music files are replaygained to 89DB(which is basically a(static for the whole file) + or - DB value, the value can never be higher than any value that would cause clipping in that particular file. Quiet files get amplified the same way so the loudest sound sounds like 89DB without clipping)
Foobar 2000 is the player with the following settings>
-Secret Rabit code resampler resamples to 96000 (to avoid crappy windows and hardware resamplers)
-Noise Sharpener DSP at 100% (this is a very good DSP)
-Advanced Limiter (prevents clipping dynamically, acts as a backup)
-Pad bitdepth to 32bit(this is the bitdepth my soundcard works with, dithering is enabled but i doubt it does anything)
-ASIO directly to soundcard(bypassing the crappy windows kmixer)
-Soundcard to speakers, speaker volume set to 25%
-Windows master volume is set to 100%
-Foobar master volume is set to 100%

The speakers are used for other devices too, the 25% is accurate for everything i use except movies on the pc.

Although replaygain is very nice because it calculates the phychoaccoustic best value, any other method will be fine for me as long as:

-The maximum loudest sounds do not get any louder than what replaygain is currently doing with music
-dynamic range is fully retained (quiet scenes to not get amplified to the point where they are almost as loud as explosions)

(i'm basically trying to simulate the entire foobar2000 chain in ffdshow for movies)

tal.aloni

24th October 2008, 21:14

Normalize up to 400%, this will change the volume dynamically to make all scenes sound equally as loud, it will re-evaluate the loudness every few seconds to see if the amplifictation needs to be changed. Some dynamic range could be lost as quiet scenes are amplified more than explosions.
this is true if you check "Regain volume".
when "Regain volume" is unchecked, the dynamic range is ultimately fully retained.

Mr VacBob

24th October 2008, 21:36

Thank you, I have sent your sample to the author.

I finally got a chance to check this sample and it looks fine to me with mplayer+mt. Is there a timestamp problem or is it something you can screenshot? If it's a timestamp problem, are you using reordered_opaque?

ikarad

24th October 2008, 21:51

I have one question about FFDSHOW H264 codec.
This codec is only dual core multithread codec and not quad core multithread core (only two cores and not quad core are used when I play a H264 movis).
I would like to know if a new version of H264 codec used by ffdshow will bring the use of quad core.

thanks

tetsuo55

24th October 2008, 21:51

this is true if you check "Regain volume".
when "Regain volume" is unchecked, the dynamic range is ultimately fully retained.

Allright,

Next question

Normalize > Maxamplification.

Do i understand correctly that:
-You set the maximum value here, but this value i also the target, everything gets played back at this amp level
-the value is lowered to prevent loudness based on the history of the file, after a while it find an almost perfect value and stays there
-the value will be lowered even further if clipping is detected

Leak

24th October 2008, 22:40

Music files are replaygained to 89DB(which is basically a(static for the whole file) + or - DB value, the value can never be higher than any value that would cause clipping in that particular file. Quiet files get amplified the same way so the loudest sound sounds like 89DB without clipping)
Those "89dB" actually are a level the *average* volume of the whole file is adjusted to.

That doesn't mean there won't be any parts that exceed it (it's not the same as normalization), only that the whole file on average will have a pre-set level, and usually you take a handful of files (like separate songs or full albums) and use replaygain to adjust them to a similar volume so you won't get your ears blown out by that one album that's compressed to hell and back.

Replaygain itself does not do sound compression or anything similarly drastic - it just calculates an amplification factor for a whole file by attenuating several frequency bands (just for analysis, mind you) differently to kinda simulate the human hearing system. The average volume will then be calculated based on the filtered result, and the amplification factor will usually be clipped at the highest possible value that doesn't cause clipping if need be.

It does wonders for my MP3 files, but it's usually applied once directly to the files, not done on the fly.

np: T.Raumschmiere - Brenner (ft. Deichkind & The Crack Whore Society) (I Tank U)

tetsuo55

24th October 2008, 23:23

Those "89dB" actually are a level the *average* volume of the whole file is adjusted to.

That doesn't mean there won't be any parts that exceed it (it's not the same as normalization), only that the whole file on average will have a pre-set level, and usually you take a handful of files (like separate songs or full albums) and use replaygain to adjust them to a similar volume so you won't get your ears blown out by that one album that's compressed to hell and back.

Replaygain itself does not do sound compression or anything similarly drastic - it just calculates an amplification factor for a whole file by attenuating several frequency bands (just for analysis, mind you) differently to kinda simulate the human hearing system. The average volume will then be calculated based on the filtered result, and the amplification factor will usually be clipped at the highest possible value that doesn't cause clipping if need be.

It does wonders for my MP3 files, but it's usually applied once directly to the files, not done on the fly.

np: T.Raumschmiere - Brenner (ft. Deichkind & The Crack Whore Society) (I Tank U)

thanks for explaining it in more detail, thats exactly what i want in movies

SCRATCHY

24th October 2008, 23:54

sorry to bother, does anyone know if it's possible to have less blurry SRT subs ?

there's no option to check like in vobsub ? :(

is it possible to have less AA on the subs ? I find them a tad blurry..

tal.aloni

25th October 2008, 00:59

Here are some screens taken with Avisynth,
as you can see, something bizarre is happening:
http://iknowu.net/files/public/ffdshow/MT/Frame31-MT.PNG
http://iknowu.net/files/public/ffdshow/MT/Frame46-MT.PNG
http://iknowu.net/files/public/ffdshow/MT/Frame62-MT.PNG

here is frame 62 with CoreAVC for a comparision
http://iknowu.net/files/public/ffdshow/MT/Frame62.PNG

I've got phenom x3 8450 and Abit A-N78HD mobo.

p.s. ignore the wrong colorspace

tal.aloni

25th October 2008, 01:03

thanks for explaining it in more detail, thats exactly what i want in movies

you'd want the peak at 100%, above then that, you'll get clipping, below that, you'll get unnecessary static noise from the amplifier.

what you really want is one-pass norm, luckily, now you have it. :)

Tal

p.s. yes, you understood correctly.

cc979

25th October 2008, 10:42

@tal.aloni

i have a question about the normalizer in previous posts you mentioned the buffer was not used anymore, does it use another form of look-ahead or does it have headroom to prevent some clipping ?

cheers

MatMaul

25th October 2008, 11:31

Then why on earth gabest had to write that complicated code?
He had to have good reason.
don't know...
but misinterpreting progressive DVD as TFF to correctly detect some broken non compliant files is not very good I think.

what about the other part of the patch for hw deinterlacing ?

haruhiko_yamagata

25th October 2008, 11:38

don't know...
but misinterpreting progressive DVD as TFF to correctly detect some broken non compliant files is not very good I think.
Correct, but it has long history. We have to do it in a careful way. Open test is a good idea.

what about the other part of the patch for hw deinterlacing ?
I think it's good. I have just finished porting yadif, so I may have time to test.

MatMaul

25th October 2008, 11:41

one thing I forgot : with that patch libmpeg2 detection matchs libavcodec detection.

I can make a build and post it.

EDIT : here is a build (http://www.etud.insa-toulouse.fr/~mvelten/bordel/ffdshow_rev2247_libmpeg2_test.zip)
please first install a recent trunk version from sourceforge (not the albain test builds) and copy ffdshow.ax into your ffdshow directory

tal.aloni

25th October 2008, 13:16

in previous posts you mentioned the buffer was not used anymore, does it use another form of look-ahead or does it have headroom to prevent some clipping?

1. the buffer was not used to look ahead, it was used to look back.
2. yes, it does have some headroom. we only regain 6% in each second, and only when the latest sample maximum (last 0.2 seconds usually) is amplified to less then 0.75f.

Tal

tetsuo55

25th October 2008, 16:24

you'd want the peak at 100%, above then that, you'll get clipping, below that, you'll get unnecessary static noise from the amplifier.

what you really want is one-pass norm, luckily, now you have it. :)

Tal

p.s. yes, you understood correctly.

So master volume 100% or 20%?

tal.aloni

25th October 2008, 16:59

So master volume 100% or 20%?

100% is much preferred.
that is, if you're willing to forget about you're precious 89db.

p.s.
don't you have audible white noise coming from your speakers with your correct config?

KoD

25th October 2008, 17:01

Some interface bugs in albain's ffdshow build 2239 (and any other ffdshow build as well, but considering he's the one in charge of audio development right now...)
1. ffdsow audio decoder -> codecs as follows:
MP3 = libavcoded
MP1, MP2 = libavcodec
AC3 = libavcodec
DTS = libavcodec
AAC = libfaad2
Vorbis = libavcodec
2. trying to play the file [CCCP]_Mega_Audio_Test.mkv file from here (http://www.cccp-project.net/beta/index.php?dir=test_files/)
3. any mpeg 1/2/2.5 (those that are not AAC) audio track shows mp3 in the 'Info & CPU' info
4. the vorbis tracks have wrong bitrate shown in the 'Info & CPU' info
5. if instead of libfaad2, one uses realaac to decode AAC, then for those AAC profiles not supported by realaac, ffdshow throws an exception and takes the player down with it as well6
6. libavcodec is still not good enough to decode mp3. It still causes random 'clicks' on some mp3 tracks, which don't happen in the same spot when one tries to reproduce them (don't ask me for samples though)

tetsuo55

25th October 2008, 17:11

100% is much preferred.
that is, if you're willing to forget about you're precious 89db.

p.s.
don't you have audible white noise coming from your speakers with your correct config?

I'm going to use 80% for now (100% too loud), with normalize at 400%.

Well i don't really care about the 89dB i just mentioned it because replaygain says it uses it for something. My goal is purely to have everything sound equaly as loud without having to change the volume settings of my speakers

if you mean windows sounds/foobar2000 and external sources then no, the first sign of white/pink noise starts at about 70% speaker loudness and thats from the fans and harddisks in the system.

If you mean with ffdshow i did notice some settings caused white noise but with my current settings i don't hear it.

tal.aloni

25th October 2008, 19:10