Skip to main content
Topic: Ripping when Murphy strikes: is this a viable solution? (Read 948 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ripping when Murphy strikes: is this a viable solution?

First things first: hello everybody!

Almost three years passed since my last post here, but I've continued to lurk around and I still find reading here truly informative: a huge thank-you to all mods and contributors.

I'm now posting because an idea popped in my mind about how trying to rip when apparently you're really out of luck and Murphy seems to have a thing with you. Let me clarify.

I have a CD which I really like but for some reasons I always forgot to rip in lossless format (BTW it is the "Histoire du Soldat" by Igor Stravinsky, directed by Charles Dutoit in the seventies, Erato ECD 88198).

A couple of weeks ago I decided that it was time for it but I soon discovered that the CD was in really bad shape: as it already happened to an handful of other CDs it seems that the printing ink on the label side has migrated through the polycarbonate and corroded the reflective layer (anedoctically, I have the feeling that some EMI pressing have an higher tendency to develop this kind of "rot").

The CD can be read in burst mode by both my Plextor Premium and my LiteON iHAS324, but none of the twos can read it in secure mode. With the Plextor (using EAC with C2 pointers and the -usefua switch) I gave up when after more than 48 hours it was still at about 60%. But the real reason I gave up was because on Amazon I found another (used) copy on sale, which I immediately ordered.

The new CD arrived a couple of days ago and here is when Murphy revealed all of his might: the second CD too has some "ink rot"  and is un-rippable in secure mode :(

TLDR;
The two defective CDs, anyway, seems to have defects mostly in different ranges and here is the idea that popped in my mind:

I have two CDs (apparently same pressing, they are bit-aligned), CD "A" and CD "B" and two readers of different brand which interpolate uncorrectable errors in different ways, reader "1" and reader "2".

Why not rip both CDs with both readers and create a set of 4 CD images, A1, A2, B1, B2? If a certain part (frame? sample?) of a CD (say CD "A") is good or successfully corrected then it would be exactly the same when ripped from the two different drives (A1 == A2), while if it is interpolated it should be different when ripped from the two different drives.

Murphy allowing, I could then check if that part is good in the other CD by looking if B1 == B2 and then splice the "B part" in place of the defective "A part".

If Murphy stills strikes, then one could decide which one of 4 rips should be considered as a "priority" one or... could try doing a better interpolation or... try to see if CDTB could be of use in fixing the samples which are still uncorrected.

I experimented using Adobe Audition: I pasted an inverted copy of A1 into A2 and an inverted copy of B1 into B2 to find non-zero samples: and then tried to mix-and-match the good parts into a good "C" rip. The concept seems to work, but doing it manually is out of question, so here my question: is there already a piece of software for doing that? if not, are there tools in which my "algorithm" could be easily implemented? I'm thinking maybe Wolfram Mathematica could be a good one, but I don't have access to it anymore... Anything open source available?

OR... does anyone of you developers find this a good idea to implement in his product?

Thanks in advance,

Sergio
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)


Re: Ripping when Murphy strikes: is this a viable solution?

Reply #2
Thanks @Thundik81,

I've given a quick look at both of them, but apparently none of the twos can do what I'm looking for (mixing the good parts from two different audio CDs):

IsoPuzzle seems to be good for DVD (video) ISO images and only for trying to read from one DVD ignoring errors and create an ISO with a .FLG sidecar file with bad sectors flagged. Beside IsoPuzzle seems to be abandonware since about 2010.

IsoBuster, unless I'm missing something, is a commercial program with about the same features offered by EAC, CUERipper and other free or FOSS rippers. I'm not seeing anything about mix-and-matching two rip versions and I'm strongly skeptical it could read anything from the holes the migrated ink has dug into the reflective layer.

Am I missing the good part? Can you please be more specific and point me to it?

Thanks again,

Sergio
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)


Re: Ripping when Murphy strikes: is this a viable solution?

Reply #4
You do not mention if your burst mode rip was accurate, or, if not, whether CTDB was able to repair it.

That sounds like a lot of work to me. I have had similar issues in that I have encountered a handful of discs that will rip correct;y in burst mode but will choke using secure mode. In most cases the burst rip fortunately had only a few minor errors that I was able to correct using CTDB. I would suggest that you first attempt the burst rip + CTDB repair method before trying anything else.

 

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #5
What are you using to rip? Let EAC/CUETools/dBpoweramp rip as burst and check for AccurateRip matches first.
High Voltage socket-nose-avatar

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #6
FYI, the label and the reflective layer are both on the same side of the CD. Nothing migrated through the polycarbonate.

Also, I had that same performance on vinyl a long time ago, but never replaced it when I tossed my vinyl collection.


Re: Ripping when Murphy strikes: is this a viable solution?

Reply #8
Hello and thanks everybody for answering!

@Thundik81:
that sound really interesting... it goes along the lines of what I was thinking (ripping the same CDs on two different drives or ripping two different CDs on the same drive shouldn't make much a difference if the 2 CDs are of the same pressing, which apparently they are...), but I'm still unconvinced about investing into it. My main concern is about what IsoBuster would consider as a defective sector/frame/whatever and thus map it out in the ripping process. While that's easy with data CD that's not so obvious for CD-AUDIO. If I'm going to rip in burst mode (which I should as other methods simply do not work with that CDs), many errors will be hidden by the error correction performed by my drive and thus will probably not be "mapped out". This unless IsoBuster will honor C2 information provided by my Plextor drive and consider the data as bad because of it...

@Pepzhez and @Porcus:
As I mentioned in my OP the ripping(s) have been done (both with the Plextor Premium and the iHAS324) using EAC in burst mode because otherwise the ripping process would apparently last forever ( I gave up after more than 48 hours!) and unhappily in all cases it was impossible to fix it via CTDB

Here are the EAC and CueTools logs (just for one of the several rips I performed, others ar similar, with different CRCs):
Code: [Select]
Exact Audio Copy V1.3 from 2. September 2016

EAC extraction logfile from 16. April 2019, 3:17

Stravinsky/Ramuz; Charles Dutoit / L'Histoire du soldat / Renard

Used drive  : PLEXTOR CD-R   PREMIUM   Adapter: 1  ID: 0

Read mode : Burst

Read offset correction                      : 30
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  |  0:00.37 |  2:45.25 |        37    |    12436  
        2  |  2:45.62 |  6:47.18 |     12437    |    42979  
        3  |  9:33.05 |  4:55.37 |     42980    |    65141  
        4  | 14:28.42 |  4:42.20 |     65142    |    86311  
        5  | 19:10.62 |  6:28.05 |     86312    |   115416  
        6  | 25:38.67 |  0:51.40 |    115417    |   119281  
        7  | 26:30.32 |  3:42.50 |    119282    |   135981  
        8  | 30:13.07 |  6:56.48 |    135982    |   167229  
        9  | 37:09.55 |  2:57.10 |    167230    |   180514  
       10  | 40:06.65 |  6:24.10 |    180515    |   209324  
       11  | 46:31.00 |  1:20.42 |    209325    |   215366  
       12  | 47:51.42 |  0:43.18 |    215367    |   218609  
       13  | 48:34.60 |  0:41.07 |    218610    |   221691  
       14  | 49:15.67 |  5:39.68 |    221692    |   247184  
       15  | 54:55.60 |  2:19.45 |    247185    |   257654  
       16  | 57:15.30 | 16:07.32 |    257655    |   330211  


Range status and errors

Selected range

     Filename E:\Music (Converted)\Stravinsky,Ramuz; Charles Dutoit - L'Histoire du soldat , Renard (D1 burst usefua).wav

     Timing problem 0:02:45
     Timing problem 0:05:53
     Timing problem 0:08:51
     Timing problem 0:33:51
     Timing problem 1:01:46

     Peak level 77.1 %
     Extraction speed 7.9 X
     Copy CRC 8D3F165E
     Copy finished

No errors occurred

 
AccurateRip summary
 
Track  1  cannot be verified as accurate (confidence 6)  [B489E0C5], AccurateRip returned [CD03AC97]  (AR v2)
Track  2  cannot be verified as accurate (confidence 6)  [ED53501D], AccurateRip returned [09BCAD13]  (AR v2)
Track  3  cannot be verified as accurate (confidence 6)  [9AEB1F83], AccurateRip returned [5110C4F1]  (AR v2)
Track  4  cannot be verified as accurate (confidence 6)  [7F93036A], AccurateRip returned [4ADEA876]  (AR v2)
Track  5  cannot be verified as accurate (confidence 6)  [87D4CA05], AccurateRip returned [B9D33F13]  (AR v2)
Track  6  cannot be verified as accurate (confidence 6)  [2AE78ABF], AccurateRip returned [45AB1965]  (AR v2)
Track  7  cannot be verified as accurate (confidence 5)  [0AA5992B], AccurateRip returned [DB3F54E6]  (AR v2)
Track  8  cannot be verified as accurate (confidence 6)  [3BC7B4C6], AccurateRip returned [87676386]  (AR v2)
Track  9  cannot be verified as accurate (confidence 4)  [FADE1430], AccurateRip returned [96254DDA]  (AR v2)
Track 10  cannot be verified as accurate (confidence 4)  [953D18FB], AccurateRip returned [28FE746E]  (AR v2)
Track 11  cannot be verified as accurate (confidence 6)  [60635EB0], AccurateRip returned [2487EEA4]  (AR v2)
Track 12  cannot be verified as accurate (confidence 6)  [065FE9CE], AccurateRip returned [E5A77B30]  (AR v2)
Track 13  cannot be verified as accurate (confidence 7)  [058AA8E7], AccurateRip returned [BCCBEFCC]  (AR v2)
Track 14  cannot be verified as accurate (confidence 5)  [31065932], AccurateRip returned [37262AD3]  (AR v2)
Track 15  cannot be verified as accurate (confidence 5)  [C304515A], AccurateRip returned [CB9AE945]  (AR v2)
Track 16  cannot be verified as accurate (confidence 1)  [B336F322], AccurateRip returned [0B5FA14F]  (AR v2)
 
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report

---- CUETools DB Plugin V2.1.6

[CTDB TOCID: sngadtTAOMY9Obp20XWANiNGJ5s-] found
Submit result: insufficient quality
Track | CTDB Status
  1   | (0/2) No match
  2   | (0/2) No match
  3   | (0/2) No match
  4   | (0/2) No match
  5   | (0/2) No match
  6   | (0/2) No match
  7   | (0/2) No match
  8   | (0/2) No match
  9   | (0/2) No match
 10   | (0/2) No match
 11   | (0/2) No match
 12   | (0/2) No match
 13   | (0/2) No match
 14   | (0/2) No match
 15   | (0/2) No match
 16   | (0/2) No match
Code: [Select]
[CUETools log; Date: 2019-04-18 21:15:13; Version: 2.1.7]
Pregap length 00:00:37.
[CTDB TOCID: sngadtTAOMY9Obp20XWANiNGJ5s-] found.
Track | CTDB Status
  1   | (0/2) No match
  2   | (0/2) No match
  3   | (0/2) No match
  4   | (0/2) No match
  5   | (0/2) No match
  6   | (0/2) No match
  7   | (0/2) No match
  8   | (0/2) No match
  9   | (0/2) No match
 10   | (0/2) No match
 11   | (0/2) No match
 12   | (0/2) No match
 13   | (0/2) No match
 14   | (0/2) No match
 15   | (0/2) No match
 16   | (0/2) No match
[AccurateRip ID: 00280f64-01d9c133-f1113210] found.
Track   [  CRC   |   V2   ] Status
 01     [1a0ad030|b489e0c5] (00+00/08) No match
 02     [50882b35|ed53501d] (00+00/08) No match
 03     [d7340f86|9aeb1f83] (00+00/08) No match
 04     [2186eaf5|7f93036a] (00+00/08) No match
 05     [0d9bd77a|87d4ca05] (00+00/08) No match
 06     [96e289b4|2ae78abf] (00+00/08) No match
 07     [6ce0df5c|0aa5992b] (00+00/07) No match
 08     [89acdb87|3bc7b4c6] (00+00/08) No match
 09     [cf455ff5|fade1430] (00+00/06) No match
 10     [f3c1b1ae|953d18fb] (00+00/06) No match
 11     [d8d836d1|60635eb0] (00+00/08) No match
 12     [d9590750|065fe9ce] (00+00/08) No match
 13     [bf0c88ac|058aa8e7] (00+00/09) No match
 14     [86189db7|31065932] (00+00/05) No match
 15     [154b9503|c304515a] (00+00/05) No match
 16     [fd2cf07e|b336f322] (00+00/10) No match

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   77.1 [8D3F165E] [24FCFC40]   CRC32  
 01   72.5 [BC5BD453] [4AA089FE]          
 02   56.4 [1F4B3CF2] [B1A60139]          
 03   73.2 [762DF58A] [22093D2B]          
 04   57.9 [FA636900] [C12238F6]          
 05   67.5 [B949140F] [AFA084E5]          
 06   33.8 [C17B6CB4] [B225A5A2]          
 07   67.3 [13113200] [8F26A0AE]          
 08   77.1 [1003004A] [9F106B44]          
 09   53.3 [110BCF5C] [F194D4CA]          
 10   55.6 [30B6EA49] [6A42231D]          
 11   64.5 [E19A7C6F] [065AD6DB]          
 12   49.1 [59F86D31] [CCB58474]          
 13   54.7 [ACD421B1] [D0B87449]          
 14   32.4 [0FC5A3F1] [8528802D]          
 15   73.5 [E5076AB6] [9E912A6B]          
 16   76.7 [0B32E862] [D4B42E05]          

@pdq:
Yeap! You are right and I stand corrected: the ink migrated through the lacquer protective, not the polycarbonate layer

@2tec:
that's not my CD: that's the Markevitch performance, which I have too, but honestly I prefer the Dutoit's one. The Dutoit's CD seems to be quite uncommon: Discogs does not list the original CD edition (Erato ECD 88198), but only a later reprint, Erato 2292-45403-2, which has a slightly different cover and which very few seems to have. See https://www.discogs.com/release/12077088 (The original LP is @ https://www.discogs.com/master/1183322).

Thanks again to all!
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #9
Doesn't look good for repair with CTDB.
http://db.cuetools.net/?tocid=sngadtTAOMY9Obp20XWANiNGJ5s-
both records are confidence 1
http://cue.tools/wiki/CTDB_EAC_Plugin#Known_issues
Quote
Known issues
    CTDB accepts the recovery record portion of a submission when the plugin reports the rip quality as 100%, but since EAC (V1.0 beta 2 through V1.0 beta 4) doesn't report suspicious positions to the plugin, the quality may be reported to CTDB as 100% when it is actually less than that. This causes CTDB to wrongly accept a recovery record which could be used to "repair" future rips to match the bad rip. It is recommended to avoid doing a repair when the CTDB confidence is 1/x

I can add some info you don't see:
CTDBID 748F09CB was ripped using a newer version of the plugin but only had a rip quality of 87% so more than a few rereads and no recovery record.
CTDBID BF2B1E18 was ripped using an older version of the plugin so though quality was reported as 100% and has a recovery record, a repair shouldn't be trusted due to the confidence level.
korth

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #10
Quote
Doesn't look good for repair with CTDB.
Sadly I agree...  :(

What do you think about my wild idea of mix-and-matching the rip of two different CDs?

At this point, if there is nothing already developed for that, I'm thinking about writing an ad-hoc program, probably in Python using the wave.py library. I'm not a Python programmer (I usually write PHP and C++ code at this time), but this could be a good opportunity to learn something about it. Beside I never tried to read .wav files and I'm wondering if it would be easier to treat raw PCM files instead...

Any advice would be really appreciated.

Cheers,

Sergio
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #11
The problem is what to keep, right?

Assuming that you are willing to work a bit more than the CDs are worth - sometimes we fight stuff like this just for the sport, eh?

* Use two CD drives. Different ones. Call them "X:" and "Y:". Call the CDs "A" and "B".
* Four rips will make AX AY BX BY.
* "Range by range": If a certain range is OK in one CD, say A, then AX and AY should agree. Conversely, it isn't that easy for two different drives to agree on a destroyed CD.
So if AX and AY agree while BX and BY don't, then the first guess would be that CD A is "correct" about the range in question.

The first thing you do, is to make a burst rip to image. That gives you a cuesheet. Everything else can be fixed by patching together .wav files later. Then about ranges: Using a bitcompare utility, you can find out where in each track is the first disagreement.  Using EAC you can set range (uh ... I think I remember so.) Say, you got a few minutes first that are OK, then make Range1.wav. Then choose Range2 and rip ...
Finally you will have Range1.wav up to RangeN.wav. Line these up and concatenate them using e.g. fb2k's conversion function, get a single CDImage.wav, and then use the cuesheet you initially created.
High Voltage socket-nose-avatar

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #12
Hi @Porcus!

Quote
... sometimes we fight stuff like this just for the sport, eh?

Absolutely!  :D

Quote
* Use two CD drives. Different ones. Call them "X:" and "Y:". Call the CDs "A" and "B".
* Four rips will make AX AY BX BY.
* "Range by range": If a certain range is OK in one CD, say A, then AX and AY should agree. Conversely, it isn't that easy for two different drives to agree on a destroyed CD.
So if AX and AY agree while BX and BY don't, then the first guess would be that CD A is "correct" about the range in question.

Yeap! "great minds think alike"  8)
That's exactly what I proposed in my OP:
Quote
I have two CDs (apparently same pressing, they are bit-aligned), CD "A" and CD "B" and two readers of different brand which interpolate uncorrectable errors in different ways, reader "1" and reader "2".

Why not rip both CDs with both readers and create a set of 4 CD images, A1, A2, B1, B2? If a certain part (frame? sample?) of a CD (say CD "A") is good or successfully corrected then it would be exactly the same when ripped from the two different drives (A1 == A2), while if it is interpolated it should be different when ripped from the two different drives.

Murphy allowing, I could then check if that part is good in the other CD by looking if B1 == B2 and then splice the "B part" in place of the defective "A part".

Only problem I see with your method of splicing the presumably good parts is that in my case there are too many of them to be realistically manually spliced together by re-ripping ranges with EAC and then gluing them together using F2K.

I think I'll move forward and try to write a (Python ?) program to do that automatically using the original 4 rips. I'll let you know...

But... couldn't it be a good idea to add such functionality to EAC and/or CUERipper?  ::)
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #13

@2tec:
that's not my CD: that's the Markevitch performance, which I have too, but honestly I prefer the Dutoit's one. The Dutoit's CD seems to be quite uncommon: Discogs does not list the original CD edition (Erato ECD 88198), but only a later reprint, Erato 2292-45403-2, which has a slightly different cover and which very few seems to have. See https://www.discogs.com/release/12077088 (The original LP is @ https://www.discogs.com/master/1183322).


So, if I understand correctly, the CD you have isn't listed in Discogs yet. Perhaps you could add it? I find that after I've added a release, it often is populated with either people listing it in their collections and then possibly, selling a copy.

Also, sometimes libraries have copies, have you checked your local library?
Quis custodiet ipsos custodes?  ;~)

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #14
<ot>
So, if I understand correctly, the CD you have isn't listed in Discogs yet. Perhaps you could add it?
Correct, it is not listed on Discogs, and yes, I can add it.
Only problem is I'm not much familiar with the process, especially in this case where I should add a different version of an already listed CD https://www.discogs.com/release/12077088 of 1993, while I'm quite sure my version predates the listed one: my CD doesn't report a date, but from the catalog number, ECD 88198, it should had been issued in 1986 as both ECD 88181 and ECD 88211 are listed for 1986 and it also match my recollection of when I bought it (between 1986 and 1987).
Shouldn't in this cases a "/master/" entry be created under which both releases should be listed?
If you want to help me with this, please get in touch with me directly on Discogs, where I'm "smanzi"
Cheers!
Sergio
</ot>
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #15
Quote
I have a CD which I really like but for some reasons I always forgot to rip in lossless format
Does that mean you have a "perfectly good" lossy copy?  ;)

I don't think you mentioned if you were getting audible errors in burst mode?

And, you didn't mention if the CD plays OK.   If it plays without audible defects, you can make an "analog" recording.

If you can't hear the defects, my advice is to try not to worry about it and enjoy the music!    I have a few CDs that had ripping errors or AccurateRip errors but as long as they sound OK, or if I was able to make a "repair" with an audio editor, or download an MP3, etc.,  I have literally forgotten which CDs were "bad".   In a few cases, I've burned a new CD which is not digitally-perfect but it sounds OK and it can be played or ripped without (further) errors.   If I open a jewel case and find a burned CD that's a reminder that there was a problem with the original but it doesn't detract from my enjoyment of listening.

Most of my CDs were ripped before I had AccuateRip (before AccuratRip existed, I think) an I've NEVER had an audible error when EAC says "no errors", even when I had AccurateRip and it indicated a mismatch.   And sometimes EAC will report a "possible error" but I can't hear a defect.

AccurateRip is a GREAT tool but CDs and music are for listening enjoyment!   ;)


Re: Ripping when Murphy strikes: is this a viable solution?

Reply #16
Well, @DVDdoug, you almost had me with that!  :D

As I said in the OP the CDs are in a really bad shape (both of them, but particularly my original one, a little bit less so the second one I bought on Amazon). With that I mean that at times (frequently on the original) I can easily hear a lot of "tshik-tshik-tshiks". I also took my old Revox B126 out of the attic and tried with it, but, helas, it is even worse with it (btw, it's on sale if anyone is interested...).

Of course that doesn't takes anything away from Stravinsky's music or Dutoit's performance, but every "tshik" is a reminder that I'm an idiot for not having backed-up the CD before the darn ink did his nasty work on the precious substrate.

Beside there is the dark obsessive side of myself that can't tolerate a single bit out of place, but that's another story, and I must admit you're much wiser than I am about that...

And of course there is also the "challenging" aspect of trying to fix the problem (and put order back in the Universe??  ::)), which is another good reason for trying (I'm right now learning how to read .wav files in Python, and it's interesting...)

Cheers!
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #17
Hello, everybody: just a quick note to let you all know that I'm starting to hate the Python wave module: it is really easy to read a WAV file with it. Only problem is that it returns audio frames into a "bytes" object and in Python "bytes" objects are immutable (you can't assign values to them)  :o
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #18
That's exactly what I proposed in my OP:
Gosh. I had read something like it recently yeah, and it was this very thread.
*facepalming*

I'm getting demented.
High Voltage socket-nose-avatar

Re: Ripping when Murphy strikes: is this a viable solution?

Reply #19
Welcome to the club, @Porcus!   ;)
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

 
SimplePortal 1.0.0 RC1 © 2008-2019