[MP3 ENCODER] test
THE DOUBLER - NEW BUY OPINION: European American Resources, Inc. Symbol: EPAR (OTCBB) Recent Price - $.375 52 Week Range - $.21875 - $1.6875 Estimated Float - 5.9 Million Shares Outstanding - 16.2 Million Shares Gold mining stocks have been a neglected group during this great Bull Market. Many financial advisors suggest putting a small percentage of a portfolio (3-10%) into precious metals as a hedge against inflation. With oil prices hitting multi-year highs, we are advising purchase of European American Resources (EPAR), currently trading near the low for the year. EPAR'S largest property in Nevada is located right between two successful gold mines operated by Homestake Mining (HM-NYSE-5 5/8), one of the top gold companies in North America. EPAR recently agreed to a joint venture with HM, where Homestake is financing 100% of the drilling costs. If the digging is promising, European American could be a takeover candidate at a high multiple to the current price. In fact, HM has acquired three of the last five companies that they entered into similar joint ventures with. Also, Nevada is known as one of the lowest-cost areas to mine gold, and EPAR'S Prospect Mountain property is right next door to HM'S Ruby Hill, which runs at a rock bottom cost of $64 per ounce to mine gold. Our philosophy is to buy stocks with the potential of doubling over a short-term period. After they reach the doubling point, we advise selling half of your position, so the remaining shares are in your portfolio on a "FREE" basis. We recommend buying EPAR at any price up to $1.50 per share. DISCLAIMER: The Doubler has received a fee of 5000 shares of European American Resources, Inc. common stock for the writing and distribution of this report. The Doubler and/or its affiliates currently own shares of EPAR, and may buy or sell shares at any time after the dissemination of this report. Because the publisher owns this stock, there may be a conflict of interest in The Doubler's statements and opinions. The Doubler is not a registered investment advisor, broker or dealer. Purchase of this stock may be considered speculative, and may result in the loss of some or all of any investment made. If you would like to be included in our mailing list to receive information regarding possible stock possibilites, e-mail us at [EMAIL PROTECTED] or print out this letter, fill in the blanks and fax us at (727) 942-0341. Name_ E-mail Address Telephone Number: ( )___ - _ If you would like to be removed from our mailing list, please e-mail us at [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test please ignore
After monday I got only two messages ( both on wednesday ) : - [MP3 ENCODER] test please ignore , from Jan Penman - [MP3 ENCODER] presets , by Robert Hegemann David Balazic Robert Hegemann wrote: test please ignore is this list dead? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test please ignore
| After monday I got only two messages ( both on wednesday ) : | | - [MP3 ENCODER] test please ignore , from Jan Penman | - [MP3 ENCODER] presets , by Robert Hegemann | | David Balazic me too. Maybe holidays? Jaroslav Lukesh -- note: (Bill) Gates to Hell! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test please ignore
| After monday I got only two messages ( both on wednesday ) : | | - [MP3 ENCODER] test please ignore , from Jan Penman | - [MP3 ENCODER] presets , by Robert Hegemann | | David Balazic me too. Maybe holidays? Hey, that sounds cool: World Wide Vacation or a little bit sloppy: WWW Jaroslav Lukesh -- note: (Bill) Gates to Hell! Ciao Robert -- Sent through GMX FreeMail - http://www.gmx.net -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test please ignore
I've had problems reaching sites in Sweden lately, I can't hit anything in Sweden and then all of a sudden, it works... That may have something to do with the mailing list problems. - Original Message - From: "Robert Hegemann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 31, 2000 3:27 AM Subject: [MP3 ENCODER] test please ignore test please ignore is this list dead? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] test please ignore
test please ignore -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] test mail
please ignore it this is a test mail. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Test PCM files
Only a small hint. The test PCM files out there are hard cutted. There's no envelope used at the start and the end. But it sound more pleasant if a short fade in and fade out is used. The ear becomes not so fast tired. For a couple of files I have done this on my computer. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] test sample
Hello, I have a interesting (I think) test sample (.wav ~1.6MB), which consists mainly of cymbal hits, with some drums and bass. The problem here is the the cymbal hits. Small reports using lame 3.70 (the last stable release) and 3.85b (last beta?) is below. However: the CBR result was better (though not very at 128kbs) in 3.70; VBR performs better than ABR and CBR with 3.85b. in 3.85b I'm a little bit worried by the VBR quality setting, which produce fully different behavior (average bitrate) than in 3.70. If somebody is interested in getting the .wav for more testing, just tell me where to upload it. Pierre --- lame 3.70 CBR 96 horrible/artefacts CBR 128 acceptable/slight artefacts VBR 6 (107kbs) poor/artefacts VBR 5 (123kbs) poor VBR 4 (163kbs) correct lame 3.85b (--lowpass 15 for all VBRs) CBR 96 horrible/artefacts CBR 128 acceptable/artefacts CBR 192 good VBR 9(119kbs) acceptable/slight artefacts VBR 8(125kbs) acceptable VBR 7(131 kbs) correct VBR 6(136 kbs) correct VBRnew 9 (147kbs) good ABR 128 (134kbs) acceptable/sligth artefacts Conclusion: great improvement of VBR_rh from 3.70 to 3.85b ABR slightly better than CBR VBR slightly better than ABR and CBR VBR_mt and VBR_rh quality similar ? CBR 128 better with 3.70 default low pass two low in VBR modes need -V 10 in VBR !! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test sample
Symbals are probably the instrument that is most difficult to encode correctly! Pierre Hugonnet wrote: Hello, I have a interesting (I think) test sample (.wav ~1.6MB), which consists mainly of cymbal hits, with some drums and bass. The problem here is the the cymbal hits. Small reports using lame 3.70 (the last stable release) and 3.85b (last beta?) is below. However: the CBR result was better (though not very at 128kbs) in 3.70; VBR performs better than ABR and CBR with 3.85b. in 3.85b I'm a little bit worried by the VBR quality setting, which produce fully different behavior (average bitrate) than in 3.70. If somebody is interested in getting the .wav for more testing, just tell me where to upload it. Pierre --- lame 3.70 CBR 96 horrible/artefacts CBR 128 acceptable/slight artefacts VBR 6 (107kbs) poor/artefacts VBR 5 (123kbs) poor VBR 4 (163kbs) correct lame 3.85b (--lowpass 15 for all VBRs) CBR 96 horrible/artefacts CBR 128 acceptable/artefacts CBR 192 good VBR 9(119kbs) acceptable/slight artefacts VBR 8(125kbs) acceptable VBR 7(131 kbs) correct VBR 6(136 kbs) correct VBRnew 9 (147kbs) good ABR 128 (134kbs) acceptable/sligth artefacts Conclusion: great improvement of VBR_rh from 3.70 to 3.85b ABR slightly better than CBR VBR slightly better than ABR and CBR VBR_mt and VBR_rh quality similar ? CBR 128 better with 3.70 default low pass two low in VBR modes need -V 10 in VBR !! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test sample
Since I've seen that the last beta was 3.86b, I tested it on the same sample. The improvement over 3.85b is significant, and now I can ear almost no artefact but on CBR 128 and below: lame 3.86b (--lowpass 15 for all VBRs) CBR 96 horrible/artefacts CBR 128 acceptable/slight artefacts CBR 192 good VBR 9(120kbs) acceptable VBR 8(127kbs) acceptable VBR 7(133kbbs) correct VBR 6(140 kbs) correct VBRnew 9 (117kbs) acceptable VBRnew 6 (135kbs) correct-good ABR 128 (128kbs) acceptable Just a remark: the default VBR mode seems to be still --vbr-old (and not --vbr-new, as suggested by the doc). Pierre Pierre Hugonnet wrote: Hello, I have a interesting (I think) test sample (.wav ~1.6MB), which consists mainly of cymbal hits, with some drums and bass. The problem here is the the cymbal hits. Small reports using lame 3.70 (the last stable release) and 3.85b (last beta?) is below. However: the CBR result was better (though not very at 128kbs) in 3.70; VBR performs better than ABR and CBR with 3.85b. in 3.85b I'm a little bit worried by the VBR quality setting, which produce fully different behavior (average bitrate) than in 3.70. If somebody is interested in getting the .wav for more testing, just tell me where to upload it. Pierre --- lame 3.70 CBR 96 horrible/artefacts CBR 128 acceptable/slight artefacts VBR 6 (107kbs) poor/artefacts VBR 5 (123kbs) poor VBR 4 (163kbs) correct lame 3.85b (--lowpass 15 for all VBRs) CBR 96 horrible/artefacts CBR 128 acceptable/artefacts CBR 192 good VBR 9(119kbs) acceptable/slight artefacts VBR 8(125kbs) acceptable VBR 7(131 kbs) correct VBR 6(136 kbs) correct VBRnew 9 (147kbs) good ABR 128 (134kbs) acceptable/sligth artefacts Conclusion: great improvement of VBR_rh from 3.70 to 3.85b ABR slightly better than CBR VBR slightly better than ABR and CBR VBR_mt and VBR_rh quality similar ? CBR 128 better with 3.70 default low pass two low in VBR modes need -V 10 in VBR !! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- +---++ | Pierre Hugonnet | mailCGG| | | 1, rue Leon Migaux | | RD Data Processing | 91341 MASSY cedex | | | FRANCE | | COMPAGNIE GENERALE DE GEOPHYSIQUE | phone...(33) 164 47 45 59 | | Paris Processing Centre | fax.(33) 164 47 32 49 | |http://www.cgg.com | [EMAIL PROTECTED] | +---++ My opinions are not necessarily those of CGG -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] test, please ignore
testing the list, please ignore this mail... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] test
test
[MP3 ENCODER] test
sorry for test, but I do not receive any message for 2 days. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test
Me neither ! Jaroslav Lukesh wrote: sorry for test, but I do not receive any message for 2 days. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] test
Hiho, Florian Forster [EMAIL PROTECTED] ! On Fri, 5 May 2000 15:53:34 +0200 you wrote: All are killed by I-LOVE-YOU virus :-) you call this a VIRUS??? all they need is the right os... ;)) plus the 'right' mail-client ... Karsten -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Test and introduction...
Layer II VBR is ISO compliant. However, players are not required to support it (unlike layer III players). Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3tech.org - Message d'origine - De : Patrick De Smet [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé : vendredi 10 décembre 1999 11:29 Objet : Re: [MP3 ENCODER] Test and introduction... On Thu, 9 Dec 1999, Gabriel Bouvigne wrote: I think he's reffering to the last LAME release able to produce identical result (bit by bit) to the ISO code. Btw, isn't Philips the only company owning a Layer II VBR encoder? Could be, and this would be a nice feature to have, but layer II VBR is not ISO-standard compliant I think; you do have a free bitrate mode; but all frames must be N or N+1 slots within this free fixed bitrate; maybe this could be incorporated into a NBC-toolame mode in the future ?? (although I don't like the idea of building something that is not standard compliant) It should be fairly easy to code this, but the hard part is finding a good decision algorithm, ie when to stop the layer II bit-allocation loop; although this could be simple too; when all MNR's hit a certain threshold just quit bitalloc; I will add this to my toolame (experiment) list which is slowly progressing again BTW; I hope to report some things next week. regards, Patrick. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Test and introduction...
Hello all, first of all this message is meant as a test message. Furthermore I would like to introduce myself and ask some questions... My name is Erik Schuijers and I'm a student at the University of Technology at Eindhoven (Holland). My pre-graduation project at Philips mainly consists of the implementation of an mp3 encoder possibly based on the ISO layer 3 encoder. In other words: within three months I will have to complete a coder which performs MUCH better (in quality and speed) as the ISO code. I've been testing around with the ISO code for a little while now and I just can't conclude anything else then that it is a bit sucky! I'm compiling under MSVC6 and I get memory read errors all over the place. Now I wondered if the original revised LAME code still existed around here somewhere. That would be a nice starting place for my project. Something else I would like to know is whether the mailing archive dates back longer. For me (and perhaps for some others too) this would make things easier in terms of comprehension of the changes made within LAME. Perhaps I can help some of you out when it comes to signal processing problems. Erik Schuijers PS: Don't think that at Philips they have all the answers to your questions... it's not like that. Fraunhofer really has a powerful position when it comes to layer 3.-- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Test and introduction...
Hi Erik, Is any of your work going to be contributed back to our community or is it going to remain proprietary? I by the way, what do you mean by "original revised LAME code"? Mark Hello all, first of all this message is meant as a test message. Furthermore I would like to introduce myself and ask some questions... My name is Erik Schuijers and I'm a student at the University of Technology at Eindhoven (Holland). My pre-graduation project at Philips mainly consists of the implementation of an mp3 encoder possibly based on the ISO layer 3 encoder. In other words: within three months I will have to complete a coder which performs MUCH better (in quality and speed) as the ISO code. I've been testing around with the ISO code for a little while now and I just can't conclude anything else then that it is a bit sucky! I'm compiling under MSVC6 and I get memory read errors all over the place. Now I wondered if the original revised LAME code still existed around here somewhere. That would be a nice starting place for my project. Something else I would like to know is whether the mailing archive dates back longer. For me (and perhaps for some others too) this would make things easier in terms of comprehension of the changes made within LAME. Perhaps I can help some of you out when it comes to signal processing problems. Erik Schuijers PS: Don't think that at Philips they have all the answers to your questions... it's not like that. Fraunhofer really has a powerful position when it comes to layer 3.-- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -=- MIME -=- Hello all, first of all this message is meant as a test message. Furthermore I would like to introduce myself and ask some questions... My name is Erik Schuijers and I'm a student at the University of Technology at Eindhoven (Holland). My pre-graduation project at Philips mainly consists of the implementation of an mp3 encoder possibly based on the ISO layer 3 encoder. In other words: within three months I will have to complete a coder which performs MUCH better (in quality and speed) as the ISO code. I've been testing around with the ISO code for a little while now and I just can't conclude anything else then that it is a bit sucky! I'm compiling under MSVC6 and I get memory read errors all over the place. Now I wondered if the original revised LAME code still existed around here somewhere. That would be a nice starting place for my project. Something else I would like to know is whether the mailing archive dates back longer. For me (and perhaps for some others too) this would make things easier in terms of comprehension of the changes made within LAME. Perhaps I can help some of you out when it comes to signal processing problems. Erik Schuijers PS: Don't think that at Philips they have all the answers to your questions... it's not like that. Fraunhofer really has a powerful position when it comes to layer 3.-- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
