IPB

Welcome Guest ( Log In | Register )

MPC VBR flaws (low volume & ringing), audible under specific conditions
guruboolez
post Jun 23 2005, 10:22
Post #1





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



Iíve read recently some complaints about musepack and distortions occurring with classical music (examples here and here). There were no ABX tests to confirm them. According to my previous listening tests at ~175 kbps, musepack performs not only very well with various kinds of instrumental and vocal samples, but also better than competitors. But Iíve also noticed in the past one issue with this audio format that my previous test didnít revealed, and itís a very big one. Iíd like to bring out this problem to the community, which wasnít as far as I know warned about this kind of flaw.

Before carrying and before some seeing zealous users bare its teeth, I have to make clear that this issue only occurs in specific conditions. The problem is confined to low-volume musical content, and is mainly audible when this content has to be listened to a higher playback volume. In other words, affected tracks must have low volume parts, and tracks with high dynamic are not really concerned (you canít constantly push the volume on such material: your neighbors wonít appreciate it). The problem becomes really critical with low-volume tracks only. People who have to live with the consequences of the ďloudness warĒ are certainly not used to encounter such tracks, but for classical fans, tracks that are replaygained at +10 dB, +20 dB and sometimes +30 dB are all except a rare thing (tracks with corrected gain beyond +25 dB are nevertheless very rare). The encoded material would exhibit strong artifacts with ReplayGan set with Track Mode (they wonít be audible otherwise, except maybe as a subtle form of distortion Ė it could explain some recent complains about musepack and classical music). With RG enabled, even untrained people will be shocked by the terrible ringing that run across this musical material. MPC, with --standard profile, and to some degree --extreme and also Ėinsane is apparently not sensitive enough to handle low volume situation.


At this stage of my account, some people would be probably tempted to claim that such issue is normal with perceptual encoding, and that all other formats will suffer from the same issue in this specific playback condition. But a quick comparison would immediately deny all validity to this idea. Iíve compared musepack --standard to comparable MP3, AAC and Vorbis presets, and these competitors showed the ability to encode properly (no ringing, flat lowpass at high level) the same material. Even stranger, MP3 at 128 kbps, or Vorbis at 90 kbps (!), or AAC (faac!) at 100 kbps perform *much* better than musepack --standard. In other words, perceptual encoders (at least modern one) could handle this situation transparently at mid/low bitrate, even with VBR; only musepack fails, and badly. It might be interesting to note that the VBR model is apparently flawed: with --standard, the bitrate drops to unusual value (110Ö140 kbps), and quality to an even more abnormal threshold. An illustration (graphical Ė listening tests were performed upstream - click for link) could make things easier to understand:



Iíve also uploaded an additional gallery - the last one looks very weird! and sounds even worse as it looks.


The ringing, and the austere lowpass, are obvious on these screenshots. Quality is objectively worse than MP3@128; subjectively speaking, the audibility is Ėas usual- linked to various conditions: hardware, player settings (RG or not), listenerí sensitivity to ringing. Some users wonít notice it, some others will be frightened. The important point to note here is that other audio formats have no problems; my purpose wasnít to make an infertile comparison between MPC and other. Based on this comparison, Iím tempted to say that MPC could rejoin them with some tuning. Anecdotal point: LAME had recently serious issue (which also concern 3.90.3 ABR at mid/low bitrate) and they were recently solved by developers. I think Gabriel worked on an adaptive ATH threshold, and it might be a lead for MPC developer or for some users which are interested to play with current encoder switches.


Iíve uploaded some samples. The gain for short samples is necessary different from the gain of complete sample; but Iíve tried to cut sample with similar gain. The WavPack samples uploaded have all the native gain and the track_peak of the full track. Iíve also duplicated the track gain to the album gain.

http://guruboolez.free.fr/MPC/quiet_tracks_replaygained.zip

Two appendix in this zip file : a piano sample for which track gain for the sample doesnít really match to the track gain of the full track (+40 dB instead of +25 dB) ; and a very noisy track for which musepack doesnít have any problem, despite of high gain correction.


This report is probably the last one Iíll do for MPC (a developer have claim their lack of interest for improving classical at --standard), but I nevertheless hope it will help to improve the encoder. Playing with command line (in order to change ATH or noise sensitivity) might be enough to solve or reduce this issue; therefore, every MPC user could contribute. In the meantime, users should be aware of this issue.

This post has been edited by guruboolez: Jun 23 2005, 10:26
Go to the top of the page
+Quote Post
 
Start new topic
Replies
Gabriel
post Jul 9 2005, 11:16
Post #2


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



Isn't the purpose of track gain to be able to use the tracks in a compilation of tracks from different albums?
In this case, why would track gain be dependant of the gain of its neighbours tracks in the original album? If someone wants to listen a full album, he would use album gain, not track gain.
Go to the top of the page
+Quote Post
Frank Klemm
post Jul 9 2005, 14:47
Post #3


MPC Developer


Group: Developer
Posts: 543
Joined: 15-December 01
From: Germany
Member No.: 659



QUOTE (Gabriel @ Jul 9 2005, 12:16 PM)
Isn't the purpose of track gain to be able to use the tracks in a compilation of tracks from different albums?
In this case, why would track gain be dependant of the gain of its neighbours tracks in the original album? If someone wants to listen a full album, he would use album gain, not track gain.
*


This is not an article about Musepack, but about flaws in the current ReplayGain
concept and implementation. Low level artefacts are related to this problem,
but this article is about ReplayGain and problems with ReplayGain. ReplayGain
ist *not* perfect at all, there's a long list of problems. Actually I use only
album based ReplayGain, other modes have a lot of problems which may significantly
reduce enjoy music.

Okay?

--------------------------------------------------------------------------------------------------------------

We should (always) start from the user application side.
And there there are at least three scenarios.

1. You want to listen to an album in original order. You want to remove volume differences between albums. The aim is to avoid volume differences between albums with different reference level, which is typical for album mastered in different decades. The effect is like a computer's turn on the volume control between albums (and by the way can also implemented in this way when the computer has access to the volume control via RS-232, RS-422, Cable LAN, Wireless LAN, IR-RC, IR-DA, USB, IEEE-1394, CAN, ...).

2. You want to listen to an album in original order. You want to remove volume differences between titels. The aim ist to reduce loudness differences inside an album, maybe also inside longer or very dynamic tracks. These loudness adjustments must be inaudible at all. No clicks, no distortions, no incredible noise boosting, no obviously loudness changes.

3. You want to shuffle titles of different album and you want to remove loudness differences between the titles. The goal is again: No clicks, no distortions, no incredible noise boosting, no obviously loudness changes.

Okay? Always start from the user application side, never start from the SSE and 3DNow!
assembler code side! Even when you like assembly programming on Intel.
Okay?

--------------------------------------------------------------------------------------------------------------

Now from the programmers geek side.

Solution for 1 is the album based replaygain and this work really great.

Solution for 2 is the proposal above. There should be a free parameter (with a useful default value) which controls the speed of the AGC. Someone want only slight loudness correction especially on title borders, another people wants to remove nearly all dynamic.

For album with silence at the title boundaries title based replaygain often works.
When there's only little loudness difference inside the album also the album gain works (see examples 2)!
There are some conceptional flaws and some flaws in the implementation.
* From time to time there are titles with (psychological) much too much title based replaygain gain
** short titles
** silent titles which must be silent at all
* file boundaries not at the real title boundaries
* live albums / classic without gaps
* noisy albums with little, but audible noise between tracks
* albums with DC
When an album has one of these problems, title based replaygain works poorly.
(see also Examples 1).

Solutions for 3 are also not so easy to implement. First of all we have problems with
boundaries (shifted, no silence). But it is not the task of replaygain to find useful
cuts or to fade between live titles during playback.

Primary goal is to remove loudness differences. Secondary goal is to avoid boosting
of intentionally silent titles. Third goal is to avoid noise boosting.

Short and very silent titles should not be boosted as much as replaygain's function GetTitleGain() says. This is important to avoid boosting of short and intentionally
silent titles.

To avoid noise boosting, ReplayGain's title gain must be limited. ReplayGain's album gain makes less problems, I only found albums with gains between -12.3 dB and +9,4 dB.
Within the title gain I found gain from -13,7 dB to +30,9 dB.

--------------------------------------------------------------------------------------------------------------

Even for 2 AND for 3 the current ReplayGain title gain is a really good implementation.
There are some flaws affecting the usage of ReplayGain title gain for problem 2 AND for problem 3. These should be fixed. In combination with a solution of the cut problem then ReplayGain title gain is also a great solution for problem 3.

Problem 2 must be solved completely different. Even when the ReplayGain title gain problems are solved, there are enough problems remaining when you want to use it
with music with
* file boundaries not at the real title boundaries
* live albums / classic without gaps
* noisy albums with little, but audible noise between tracks
* albums with DC

Examples: see next posting(s)

This post has been edited by Frank Klemm: Jul 9 2005, 15:23


--------------------
-- Frank Klemm
Go to the top of the page
+Quote Post
guruboolez
post Jul 10 2005, 23:22
Post #4





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE
This is not an article about Musepack, but about flaws in the current ReplayGain
concept and implementation. Low level artefacts are related to this problem,
but this article is about ReplayGain and problems with ReplayGain.


I beg you pardon, but you've apparently miss an important point: the problem occurs with ReplayGain and Musepack.
ReplayGain + Lame = no problem
ReplayGain + Vorbis = no problem.
ReplayGain + AAC = no problem (checked recently with Nero and previously faac)
ReplayGain + DualStream = no problem
ReplayGain + WavPack lossy = no problem
ReplayGain + MPC = problems

I won't say that ReplayGain is the cause of the problem. It's obviously MPC which can't be used safely in some situation at some encoding profiles.

QUOTE
ReplayGain ist *not* perfect at all, there's a long list of problems. Actually I use only
album based ReplayGain, other modes have a lot of problems which may significantly
reduce enjoy music.

Okay?


What should I conclude? That a problem shouldn't be considered as relevant because you have other listening habits? That's fine as long as you consider MPC as your own tool, dedicated to your own purpose and to people sharing the same behavior, and if you don't plan to improve the obvious bug occuring in other situations. But don't wonder if musepack will quickly loose its audience with such reasoning.

This post has been edited by Dibrom: Jul 11 2005, 00:14
Go to the top of the page
+Quote Post
Dibrom
post Jul 11 2005, 00:15
Post #5


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE
I won't say that ReplayGain is the cause of the problem. It's obviously MPC which can't be used safely in some situation at some encoding profiles.


I think in fact it is more correct to say that MPC can't be expected to provide good results in all situations where postprocessing of the encoded file might occur, unless the user intervenes at encode time and provides the encoder with some information that can correct for this after the fact.

This still shouldn't come as a big surprise for a lossy codec.

Yes, other codecs may not exhibit this problem, but at least in the case of some (e.g., the adaptive ATH Gabriel mentioned), it appears that they rely on tradeoff's as far as compression efficiency is concerned here. And furthermore, without 2-pass encoding being used, such an adaptive method is going to be much more imprecise.

QUOTE
What should I conclude? That a problem shouldn't be considered as relevant because you have other listening habits?


The inverse can be said just as well. Should we conclude that MPC is buggy because it doesn't perform as well as you'd like after you modified the encoded file, invalidating the assumptions the encoder made about masking, etc.?

QUOTE
That's fine as long as you consider MPC as your own tool, dedicated to your own purpose and to people sharing the same behavior, and if you don't plan to improve the obvious bug occuring in other situations. But don't wonder if musepack will quickly loose its audience with such reasoning.


Calling this a bug seems like a real stretch to me. It's not a problem with the encoder itself, it's a problem that arises when using the encoded file in certain situations that the encoder doesn't know about. Furthermore, it would seem definitely not to be a bug since the problem goes away if you in fact give the encoder the correct information at encode time (e.g., ath adjustment).

I agree with Frank -- this is not a problem with MPC but a problem with using Replaygain in this way. And that doesn't mean that there cannot be some sort of solution found, but I don't think that implementing some sort of imprecise changes in the psymodel to compensate for this special case -- sacrificing efficiency along the way -- is the right answer.

I think the proper solution is to implement some sort of multi-pass encoding system that allows for the encoder to interact with Replaygain more intelligently, if this is the way you plan to use your encoded files. Maybe this would be done by calculating the Replaygain values for the file before encoding, and then using the track gain as an indicator for ATH adjustment and the like. Of course this won't be an automatic process (you would have to specify some flag like --2pass), but I don't think it should be -- for people not planning to use their files this way, it should be unnecessary for them to have to make the efficiency sacrifices resulting in larger files.

Note: Sorry I accidently hit edit on your post instead of reply wink.gif
Go to the top of the page
+Quote Post
Gambit
post Jul 11 2005, 00:22
Post #6


Burrrn developer


Group: Developer
Posts: 917
Joined: 25-November 01
From: Bratislava, Slovakia
Member No.: 534



QUOTE (Dibrom @ Jul 11 2005, 12:15 AM)
I think in fact it is more correct to say that MPC can't be expected to provide good results in all situations where postprocessing of the encoded file might occur, unless the user intervenes at encode time and provides the encoder with some information that can correct for this after the fact.
*

Erm, we are talking about Replaygain here. In the end, it's the same as adjusting the volume knob. I would hardly call that "postprocessing".


--------------------
Burrrn - http://www.burrrn.net/
MPEG Audio Collection - http://mac.sourceforge.net/
Go to the top of the page
+Quote Post
Dibrom
post Jul 11 2005, 00:25
Post #7


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE (Gambit @ Jul 10 2005, 03:22 PM)
QUOTE (Dibrom @ Jul 11 2005, 12:15 AM)
I think in fact it is more correct to say that MPC can't be expected to provide good results in all situations where postprocessing of the encoded file might occur, unless the user intervenes at encode time and provides the encoder with some information that can correct for this after the fact.
*

Erm, we are talking about Replaygain here. In the end, it's the same as adjusting the volume knob. I would hardly call that "postprocessing".
*



Well call it what you like, but when you make significant changes to the playback level (e.g., what is happening here with classical music), it's just about as good as postprocessing as far as a psychoacoustic encoder is concerned.

The file is being processed (volume changed significantly) in a way the encoder does not expect, after the file has been encoded.
Go to the top of the page
+Quote Post
rjamorim
post Jul 11 2005, 00:28
Post #8


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (Dibrom @ Jul 10 2005, 08:25 PM)
Well call it what you like, but when you make significant changes to the playback level (e.g., what is happening here with classical music), it's just about as good as postprocessing as far as a psychoacoustic encoder is concerned.

The file is being processed (volume changed significantly) in a way the encoder does not expect, after the file has been encoded.
*


But if something as simple as turning volume knobs is tripping the codec, then the problem can't be in the volume knob :B


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
Dibrom
post Jul 11 2005, 00:33
Post #9


Founder


Group: Admin
Posts: 2958
Joined: 26-August 02
From: Nottingham, UK
Member No.: 1



QUOTE (rjamorim @ Jul 10 2005, 03:28 PM)
QUOTE (Dibrom @ Jul 10 2005, 08:25 PM)
Well call it what you like, but when you make significant changes to the playback level (e.g., what is happening here with classical music), it's just about as good as postprocessing as far as a psychoacoustic encoder is concerned.

The file is being processed (volume changed significantly) in a way the encoder does not expect, after the file has been encoded.
*


But if something as simple as turning volume knobs is tripping the codec, then the problem can't be in the volume knob :B
*



Umm.. It's not "something as simple as turning the volume knob" that is "tripping the codec." If it were, this problem would be much more pervasive and would occur practically everywhere, instead of being limited to the rather specific conditions (i.e., significant boosting of highly dynamic music to levels that invalidate encode time assumptions about masking, etc.) that guruboolez has brought up.
Go to the top of the page
+Quote Post

Posts in this topic
- guruboolez   MPC VBR flaws (low volume & ringing)   Jun 23 2005, 10:22
- - shadowking   I confirm serious problems under these special lis...   Jun 23 2005, 11:07
- - Acid8000   What I understand from your post guru is that at ...   Jun 23 2005, 11:24
- - rjamorim   I think you should put more creativity into your r...   Jun 23 2005, 15:24
- - Gambit   I haven't seen this mentioned anywhere, so I t...   Jun 23 2005, 15:41
|- - guruboolez   QUOTE (Gambit @ Jun 23 2005, 03:41 PM)QUOTE ...   Jun 27 2005, 10:27
- - Gabriel   The obvious workaround is to check the track gain ...   Jun 23 2005, 20:33
- - Lefungus   QUOTE (guruboolez @ Jun 23 2005, 11:22 AM)Thi...   Jun 23 2005, 20:33
|- - Dibrom   QUOTE (Lefungus @ Jun 23 2005, 11:33 AM)QUOTE...   Jun 23 2005, 22:01
||- - mtm   QUOTE (Dibrom @ Jun 23 2005, 11:01 PM)I would...   Jun 23 2005, 22:23
||- - GeSomeone   QUOTE (guruboolez @ Jun 23 2005, 11:22 AM)Thi...   Jun 27 2005, 12:18
|- - rjamorim   QUOTE (Lefungus @ Jun 23 2005, 04:33 PM)The c...   Jun 23 2005, 22:21
- - mtm   guruboolez, thank you very much for your input. I ...   Jun 23 2005, 21:43
- - CiTay   Thanks again for that summary, guruboolez. I alrea...   Jun 24 2005, 01:20
- - CiTay   Frank replied from work that he will comment as so...   Jun 24 2005, 10:33
- - mtm   My sincerest thanks to everyone involved.   Jun 24 2005, 14:40
- - xmixahlx   dibrom's speed enhancements were focused on PP...   Jun 27 2005, 20:32
|- - Dibrom   QUOTE (xmixahlx @ Jun 27 2005, 11:32 AM)dibro...   Jun 27 2005, 21:04
- - CiTay   As promised, here is the answer that i got from Fr...   Jun 28 2005, 20:09
- - CiTay   I'm a bit surprised nobody has to say anything...   Jul 2 2005, 21:40
|- - rjamorim   QUOTE (CiTay @ Jul 2 2005, 05:40 PM)I'm a...   Jul 2 2005, 21:56
||- - CiTay   QUOTE (rjamorim @ Jul 2 2005, 10:56 PM)Well, ...   Jul 2 2005, 22:37
|- - guruboolez   QUOTE (CiTay @ Jul 2 2005, 09:40 PM)I'm a...   Jul 5 2005, 13:33
|- - markanini   QUOTE (guruboolez @ Jul 5 2005, 01:33 PM)QUOT...   Jul 5 2005, 14:45
||- - guruboolez   QUOTE (markanini @ Jul 5 2005, 02:45 PM)I don...   Jul 5 2005, 16:17
|- - Dibrom   QUOTE (guruboolez @ Jul 5 2005, 04:33 AM)QUOT...   Jul 5 2005, 16:25
|- - guruboolez   QUOTE I think it's probably worth noting that ...   Jul 5 2005, 16:51
|- - Vertigo   QUOTE QUOTE I think it's probably worth noting...   Jul 5 2005, 17:26
- - Vertigo   Hahaha, I love it when robert comes in to save the...   Jul 3 2005, 00:54
|- - rjamorim   QUOTE (Vertigo @ Jul 2 2005, 08:54 PM)Hahaha,...   Jul 3 2005, 01:01
- - Dibrom   Do we need to split this thread again to stay on t...   Jul 3 2005, 01:32
- - Cyaneyes   Just to comment on Frank's thoughts on Track g...   Jul 3 2005, 02:43
|- - Andavari   QUOTE (Cyaneyes @ Jul 2 2005, 07:43 PM)Just t...   Jul 3 2005, 03:47
|- - Lyx   *nevermind - i mixed up trackgain and albumgain*   Jul 3 2005, 04:27
- - xmixahlx   ...if this problem only occurs in music with ridic...   Jul 3 2005, 11:29
- - Lime   I think a workaround is easy. Just do a replaygain...   Jul 5 2005, 15:10
- - Raptus   QUOTE (Gabriel @ Jun 23 2005, 11:33 AM)The fi...   Jul 5 2005, 15:41
|- - Shade[ST]   wouldnt this type of adjustment make the ath usele...   Jul 5 2005, 15:47
- - Gabriel   QUOTE wouldnt this type of adjustment make the ath...   Jul 5 2005, 16:04
|- - Dibrom   QUOTE (Gabriel @ Jul 5 2005, 07:04 AM)If I re...   Jul 5 2005, 16:46
- - Dibrom   QUOTE (guruboolez @ Jul 5 2005, 07:51 AM)QUOT...   Jul 5 2005, 17:26
|- - guruboolez   QUOTE Well haven't you gotten polite answers i...   Jul 5 2005, 18:52
- - Dibrom   QUOTE QUOTE By that, I mean that changing this in ...   Jul 5 2005, 17:26
- - Vertigo   I think we need to send Guruboolez the HA Controve...   Jul 5 2005, 17:32
|- - rjamorim   QUOTE (Vertigo @ Jul 5 2005, 01:32 PM)I think...   Jul 5 2005, 17:51
|- - Vertigo   QUOTE (rjamorim @ Jul 5 2005, 08:51 AM)QUOTE ...   Jul 5 2005, 17:57
- - Jebus   I think there seems to just be an issue with ATH a...   Jul 5 2005, 20:22
- - CiTay   I got a new e-Mail from Frank (he follows this thr...   Jul 8 2005, 22:19
|- - ChristianHJW   QUOTE (CiTay @ Jul 8 2005, 09:19 PM)I got a n...   Jul 10 2005, 09:45
- - Gabriel   Isn't the purpose of track gain to be able to ...   Jul 9 2005, 11:16
|- - Frank Klemm   QUOTE (Gabriel @ Jul 9 2005, 12:16 PM)Isn...   Jul 9 2005, 14:47
|- - Frank Klemm   Example for changing title based replaygains from ...   Jul 9 2005, 14:58
|- - Frank Klemm   Other examples where ReplayGain makes nonsense. Es...   Jul 9 2005, 15:16
||- - Frank Klemm   A lot of albums have nearly no differences between...   Jul 9 2005, 15:22
|- - guruboolez   QUOTE This is not an article about Musepack, but a...   Jul 10 2005, 23:22
||- - Dibrom   QUOTE I won't say that ReplayGain is the cause...   Jul 11 2005, 00:15
||- - Gambit   QUOTE (Dibrom @ Jul 11 2005, 12:15 AM)I think...   Jul 11 2005, 00:22
|||- - Dibrom   QUOTE (Gambit @ Jul 10 2005, 03:22 PM)QUOTE (...   Jul 11 2005, 00:25
|||- - rjamorim   QUOTE (Dibrom @ Jul 10 2005, 08:25 PM)Well ca...   Jul 11 2005, 00:28
|||- - Dibrom   QUOTE (rjamorim @ Jul 10 2005, 03:28 PM)QUOTE...   Jul 11 2005, 00:33
|||- - rjamorim   QUOTE (Dibrom @ Jul 10 2005, 08:33 PM)Umm.. I...   Jul 11 2005, 00:41
|||- - Dibrom   QUOTE (rjamorim @ Jul 10 2005, 03:41 PM)Well,...   Jul 11 2005, 00:59
|||- - rjamorim   Thanks for your clarification. So, from that, one...   Jul 11 2005, 01:02
|||- - Dibrom   QUOTE (rjamorim @ Jul 10 2005, 04:02 PM)Thank...   Jul 11 2005, 01:05
|||- - CiTay   QUOTE (Dibrom @ Jul 11 2005, 02:05 AM)'Co...   Jul 11 2005, 01:26
|||- - guruboolez   QUOTE (CiTay @ Jul 11 2005, 01:26 AM)With tha...   Jul 11 2005, 11:53
|||- - CiTay   QUOTE (guruboolez @ Jul 11 2005, 12:53 PM)Now...   Jul 11 2005, 13:01
|||- - guruboolez   QUOTE (CiTay @ Jul 11 2005, 01:01 PM)QUOTE (g...   Jul 11 2005, 14:14
||- - guruboolez   QUOTE (Dibrom @ Jul 11 2005, 12:15 AM)The inv...   Jul 11 2005, 02:18
|- - rjamorim   QUOTE (Frank Klemm @ Jul 9 2005, 10:47 AM)Rep...   Jul 11 2005, 00:13
|- - Frank Klemm   QUOTE (rjamorim @ Jul 11 2005, 01:13 AM)QUOTE...   Jul 11 2005, 18:23
|- - mtm   QUOTE (Frank Klemm @ Jul 11 2005, 07:23 PM)Th...   Jul 12 2005, 05:07
|- - Frank Klemm   QUOTE (mtm @ Jul 12 2005, 06:07 AM)QUOTE (Fra...   Jul 12 2005, 22:39
- - Gambit   It seems funny to me that you would try to fix Rep...   Jul 9 2005, 11:48
- - mtm   Thank you for your posts, Mr Klemm. They certainly...   Jul 9 2005, 18:51
- - mtm   I just want to say I agree with everything Dibrom ...   Jul 11 2005, 01:35
|- - guruboolez   QUOTE (mtm @ Jul 11 2005, 01:35 AM)I don...   Jul 11 2005, 02:26
- - Dibrom   I think I probably agree with guruboolez. I'm...   Jul 11 2005, 13:11
|- - ancl   QUOTE (Dibrom @ Jul 11 2005, 02:11 PM)I think...   Jul 11 2005, 13:33
||- - Dibrom   QUOTE (ancl @ Jul 11 2005, 04:33 AM)The 2-pas...   Jul 11 2005, 13:53
|- - CiTay   QUOTE (Dibrom @ Jul 11 2005, 02:11 PM)I think...   Jul 11 2005, 13:40
|- - Dibrom   QUOTE (CiTay @ Jul 11 2005, 04:40 AM)Yes, it...   Jul 11 2005, 13:57
|- - guruboolez   QUOTE (CiTay @ Jul 11 2005, 01:40 PM)"Ho...   Jul 11 2005, 14:27
|- - CiTay   QUOTE The current problem of MPC is not to be sure...   Jul 11 2005, 15:07
|- - guruboolez   QUOTE (CiTay @ Jul 11 2005, 03:07 PM)I don...   Jul 11 2005, 15:23
|- - CiTay   QUOTE (guruboolez @ Jul 11 2005, 04:23 PM)May...   Jul 11 2005, 15:33
|- - guruboolez   QUOTE (CiTay @ Jul 11 2005, 03:33 PM)The thre...   Jul 11 2005, 15:50
|- - CiTay   QUOTE (guruboolez @ Jul 11 2005, 04:50 PM)QUO...   Jul 11 2005, 16:03
- - 2Bdecided   I think the concentration on ReplayGain is mislead...   Jul 11 2005, 14:49
|- - guruboolez   QUOTE (2Bdecided @ Jul 11 2005, 02:49 PM)btw,...   Jul 11 2005, 15:01
|- - Dibrom   QUOTE (2Bdecided @ Jul 11 2005, 05:49 AM)The ...   Jul 11 2005, 15:14
||- - guruboolez   QUOTE Yes, but looking back the original quote fro...   Jul 11 2005, 15:35
|- - Frank Klemm   QUOTE (2Bdecided @ Jul 11 2005, 03:49 PM)The ...   Jul 11 2005, 18:14
- - CiTay   Also, guruboolez, i want to apologize to you again...   Jul 11 2005, 15:30
- - krazy   QUOTE (Frank Klemm @ Jul 12 2005, 01:23 AM)I ...   Jul 11 2005, 19:36
|- - Frank Klemm   QUOTE (krazy @ Jul 11 2005, 08:36 PM)QUOTE (F...   Jul 11 2005, 19:51
- - 2Bdecided   If you play nogap tracks out of sequence, you...   Jul 12 2005, 10:53
|- - seanyseansean   QUOTE (2Bdecided @ Jul 12 2005, 10:53 AM)A ne...   Jul 12 2005, 10:57
|- - dev0   QUOTE (2Bdecided @ Jul 12 2005, 10:53 AM)That...   Jul 12 2005, 11:17
- - guruboolez   I made a similar comparison, using short samples d...   Jul 13 2005, 00:41
2 Pages V   1 2 >


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd October 2014 - 15:50