[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: Re[2]: [MP3 ENCODER] compiling plug-ins w/ Cygwin gcc
Hi Joshua! > I see in the Makefile that __NO_MATH_INLINES was added to fix a bug in gcc > 2.8+, what bug is this, what does this do and why do you have it defined? > And what is RH_AMP? The math inlines in GLIBC libraries before 2.1.3 seem to be broken. So if you have some older GLIBC libraries installed you will have to define __NO_MATH_INLINES at compile time. I have 2.1.3 installed and math inlines seem to work, so I removed this definition (which enables math inlines). RH_AMP enables some alternate code. I mentioned it, because if someone will do the same test on those files, he can compare his results with mine. By the way, many of the test files are available at sulaco.org. > Another question would be, what version of gcc and binutils is being used > for DJGPP. I personally am using pgcc 2.95.3 and binutils 2.10, both of > which I compiled. That could make a difference. I'm still trying to figure > out why MMX_choose_table does not work (at least for me) with DJGPP. I found Hm, I had never good results with pentium optimized gcc. Every new version of it gave me different results when doing floating point calcs. So I decided for me not to use it. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Multi PCM file coding and decoding
| I don't think disk space is a problem these days. | The (big) advantage of one large mp3file containing the entire album (like | AiD suggests) is that players like winamp don't delay playback when a track | ends and another begins. When using seperate files, Winamp checks playtime, | ID3-TAG and things.. That is not the gap problem. Even when using Winamps gapless plugin you get a gap. This is due to the encoder adding a delay in the output. Try it, get a trance album or something rip a track in the middle of the CD look at the first 0.5 secs in a sample editor and you'll see NO gap. Encode the same file, decode it and then load it into the sample editor. You'll see a gap - a quite small one at the beginning. This gap is a pain in the arse and is THE thing I hate most about MP3. When this problem has been sorted in LAME i will be happy. Personnaly i feel a 'fix' to this problem is long overdue. And i don't feel it is the decoders responsibilty to remove this gap. I haven't found a perfect plugin which achieves gapless playback. You should also note that when you look at the beginning of a mp3 in spectral mode the frequencies ramp up from a low frequency to the desired one. Gapless plugins don't seem to be able to do much about this. Dave * Copyright ERA Technology Ltd. 2000. (www.era.co.uk). All rights reserved. Confidential. No liability whatsoever is accepted for any loss or damage suffered as a result of accessing this message or any attachments. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] joint-stereo and 3d-suround
Someone told me, that using -mj will destroy 3d-suround information. It is caused due switching from m/s to stereo and back. Using -mf will solves this problem, because it will not switch between the modes. In the past, i thought only fraunhofers joint-stereo has a similar problem (phase lost with is-stereo). Is this a true information, or is this false? I can not test this, because i have no equipment for that. Jack -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] The best decoders
I tried the in_mpg123 Winamp plug-in for my FM radio station a few weeks ago but I had to switch back to nitrane. If it finds a non-existing file in the playlist it just stops playing -- doesn't advance to the next song. I occasionally have this problem so I can't use it. I e-mailed Shibath but I haven't seen any progress. Ross. Eric wrote: > ...In fact I had switched from Winamp 2.5 to 2.22 from what I had read > on David's website.Now I shall try Shibath's plug-in too. I thought from > your response you had even later information,, -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi PCM file coding and decoding
> This gap is a pain in the arse and is THE thing I hate most about MP3. When > this problem has been sorted in LAME i will be happy. Personnaly i feel a > 'fix' to this problem is long overdue. Haven't made a study of the subject, but surely there is a purpose to this gap, other than that the standard dictates it (if it does)? What other reason would there be for all the encoders to put it there in the first place? Apart from this, I remember reading about a decoder gap as well-- a silent pause that the decoder put there. So it's a two-way problem. You'd need a fixed encoder as well as a fixed decoder. But I assume the Winamp gapless plugin takes care of the decoder part. Ivo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] The best decoders
On Thursday 17 Aug 00, Ross Levis writes: > I tried the in_mpg123 Winamp plug-in for my FM radio station a few weeks ago > but I had to switch back to nitrane. I read on the in_mpg123 web page that it doesn't support streaming. Could this be your problem? (I haven't tried it myself, based on this information. My personal "jukebox" is a streaming httpd server.) Cheers, David -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Sv: [MP3 ENCODER] The best decoders
Another problem in in_mpg123 is that in some files it gives a high "click" in the beginning. This problem is in mpglib, it also appears in .wav-files decoded with lame --decode (I think that Shibath has found the error, but it's still there in 3.86). So instead i have renamed the in_mp3.dll from 2.22 to in_fgh.dll and unchecked layer-3 in the Nitrane setup. That way Nitrane plays layer-2/1 only and mp3 is played by the better fgh-decoder. Peter -- 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] The best decoders
David> I read on the in_mpg123 web page that it doesn't support streaming. David> Could this be your problem? David> David> (I haven't tried it myself, based on this information. My personal David> "jukebox" is a streaming httpd server.) Sorry, I'm very busy now and can't make new version of in_mpg123. Perhaps I'll be freed by the weekend after next. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- 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 | | R&D 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/ )
Re: [MP3 ENCODER] The best decoders
> Sorry, I'm very busy now and can't make new version of in_mpg123. > Perhaps I'll be freed by the weekend after next. Well, sorry, Mr.Shibata. Actually, before their summer vacations, some people still have to work like slaves in Japan...sort of a traditional ritual at this season. And, he seems to be one of them. First, I introduced Shibath plug-in as one of the best sounding decoder in 'poplular' Win environment. So, it is still lucking of some futures that Nitrane has, of which Mr.Shibata is aware. However, fortunately or unfortunately, he is an efficient engineer as well. His company must need him as much as we. ;o) Furthermore, the point here is Nitrane has a serious bug in decoding, which is not his fault but Nullsoft's. I hope Winamp team will be able to submit bug-free decoder soon and let Mr.Shibata concentrate in LAME project. Any way, I can't go back to Nitrane any more...at least this is his fault. ;o) Cheers, Keeshond. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Optimization
> i mean in terms of speed like using faster algo like Lee's IDCT for faster > implementation. > rgds > soyeb Ok. Yes, been there, done that. The 32 point dct II, as well as the 18 point dct IV. Both with a Lee -like algorithm. Works like a charm :-) The slowest part is the polyphase windowing, and I haven't found a way to speed it up. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Optimization
You can use NamLing's algorithm for that instead og 512 mul for each iteration it will take 256 + 32 mul, i am not able to figure out how to implement recursive formulla. The Namling's paper is available at "Two polyphase filter architecture for MPEG audio",Namling,Shih, IEEE trans. speech and audio processing and another useful paper for this is "Fast implementation of MPEG audio coder using recursive formula with fast DCT", Cahn, YAng, Fang IEEE trans. speech and audio process rgds soyeb Segher Boessenkool wrote: > > > i mean in terms of speed like using faster algo like Lee's IDCT for faster > > implementation. > > rgds > > soyeb > > Ok. Yes, been there, done that. The 32 point dct II, as well as the 18 point > dct IV. Both with a Lee -like algorithm. Works like a charm :-) > The slowest part is the polyphase windowing, and I haven't found a way to > speed it up. > > Ciao, > > Segher > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] MPEG audio decoder compliance
Hello Rob, Thursday, August 17, 2000, 12:54:08 AM, you wrote: RL> If you can point me to a specific implementation I can try to test it RL> directly. The only requirement I have is that the implementation support some RL> way of saving the decoded output to a file (e.g. WAV). Would be great: http://www.daansystems.com/coolplayer maybe to be sure you can capture the output with totalrecorder. This way you can also assure that the output is the same as the .wav writer. Thanks -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Optimization
> > You can use NamLing's algorithm for that instead og 512 mul for each iteration > it will take 256 + 32 mul, i am not able to figure out how to implement > recursive formulla. > The Namling's paper is available at > "Two polyphase filter architecture for MPEG audio",Namling,Shih, IEEE trans. > speech and audio processing > and another useful paper for this is > "Fast implementation of MPEG audio coder using recursive formula with fast > DCT", Cahn, YAng, Fang IEEE trans. speech and audio process Thanks! Can I get these papers online? Ciao, Segher > rgds > soyeb -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib layer I/II decoding
Hi all! Albert Faber schrieb am Don, 17 Aug 2000: > Yesterday, I made the modification/additions in order to support layer I/II > decoding. However, since my linux environment is not running correctly right > now (and since I'm always scary to change things without testing them) I did > not made the changes to the Makesfiles (only to the MSVC project files), so > I leave that to Mark (or one of the others, the layer1.c and layer2.c files > have to be added). Moreover, I did put ifdefs around them as well, so if you > want to have support for layer 1/2 decoding you have to define USE_LAYER_1 > and LAYER_2 as well > > Albert > > http://www.cdex.n3.net/ > > mailto:[EMAIL PROTECTED] > mailto:[EMAIL PROTECTED] I just updated the Makefiles and tested LAME's new decoding capabilities with some toolame-02h generated MP2s. I did not find the time to do the same with mp[1g] files yet, maybe later. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] MPEG audio decoder compliance
> RL> If you can point me to a specific implementation I can try to test it > RL> directly. The only requirement I have is that the implementation support some > RL> way of saving the decoded output to a file (e.g. WAV). > > Would be great: http://www.daansystems.com/coolplayer > It's useless as this player uses Xaudio Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi PCM file coding and decoding
> That is not the gap problem. Even when using Winamps gapless plugin you get > a gap. > This is due to the encoder adding a delay in the output. > then why do all encoders add this gap? anyone knows this? -- grx, DataFlow -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib layer I/II decoding
Hi all! > I just updated the Makefiles and tested LAME's new decoding capabilities > with some toolame-02h generated MP2s. > > I did not find the time to do the same with mp[1g] files yet, maybe later. OK, I found the time, but with LayerI there seems to be a problem: robert@bob:~/MP3/lame-cvs/lame-2000-08-17 > lame --decode t.mpg x.wav input:t.mpg 44.1kHz MPEG1 2 channel LayerIII output: x.wav (wav format) skipping initial 1105 samples (encoder + decoder delay) Oops: mpg123 returned more than one frame! Cant handle this... Frame# 1/193149 kbpsOops: mpg123 returned more than one frame! Cant handle this... Frame# 2Oops: mpg123 returned more than one frame! Cant handle this... 3Oops: mpg123 returned more than one frame! Cant handle this... 4Oops: mpg123 returned more than one frame! Cant handle this... 5Oops: mpg123 returned more than one frame! Cant handle this... 6Oops: mpg123 returned more than one frame! Cant handle this... 7Oops: mpg123 returned more than one frame! Cant handle this... 8Oops: mpg123 returned more than one frame! Cant handle this... 9Oops: mpg123 returned more than one frame! Cant handle this... Frame#10/193148Oops: mpg123 returned more than one frame! Cant handle this... Frame#11/193149Oops: mpg123 returned more than one frame! Cant handle this... Frame#12Oops: mpg123 returned more than one frame! Cant handle this... OK, some information printings like "LayerIII" should be adapted to the real situation. But I'm actually confused about the warnings. In the end I could listen to the decoded LayerI file :) Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] XingMP3 Encoder for Linux
>From Xing dev-site: http://www.xingtech.com/support/extest/ External Testers External Testers have access to pre-release versions of Xing Products. At this time, there are no active public beta test programs. However, we are currently soliciting for qualified testers for our forthcoming release of a XingMP3 Encoder for the Linux operating system. If you are interested in becoming an external tester for this product only, please click the link on the sidebar to access the application form. Maybe some lame developer can make sure this Linux version will do things 'correct', instead of win-version ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] mp3 compressed wav files
Anyone know of any utilities that will convert an mp3 into an mp3 compressed wav file? Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi PCM file coding and decoding
:: > This gap is a pain in the arse and is THE thing I hate most about MP3. When :: > this problem has been sorted in LAME i will be happy. Personnaly i feel a :: > 'fix' to this problem is long overdue. :: :: Haven't made a study of the subject, but surely there is a purpose to this gap, :: other than that the standard dictates it (if it does)? What other reason would :: there be for all the encoders to put it there in the first place? :: :: Apart from this, I remember reading about a decoder gap as well-- a silent :: pause that the decoder put there. So it's a two-way problem. You'd need a fixed :: encoder as well as a fixed decoder. But I assume the Winamp gapless plugin :: takes care of the decoder part. :: The problem isn't so symmetric as you mentioned. * A broken°) decoder produces faulty PCM files or produces gaps on the Hifi equipment. * A broken encoder produces faulty MP3 files Now we assume the bug is fixed. What is to do: * Decoder: - Replace the decoder and be happy (if the encoder was not broken while coding the MP3 files) - Decode all PCM-from-MP3 files from their sources + Note: Usually you have all MP3 source files, because they are * much smaller * Transport of MP3 is done as MP3, not as PCM * Encoder: - Encode all PCM files again + take your own CD and borrow all CDs you have borrowed + RIP the CDs + Code the PCM files again - MP3 files you haven't code yourself + Buy the CDs, RIP the CDs and code it Note: Coding is much slower than encoding, but can be done automatically RIPing without a PC CD changer can not be done automatically The output of a decoder is mostly a temporary output so fixes have an immediate effect. Decoder output is seldom stored for a long time. Encoder output IS usually stored for a long time, is transmitted via WAN networks. That's the "little" difference. -- Mit freundlichen Grüßen Frank Klemm °) I use the term "broken" if there is a detectable (in this case audible) malfunction. If a standard (ISO, OSI, DIN, ANSI, ...) demands such a malfunction, the standard itself is broken and should be replaced by an unbroken and as much compatible as possible version. A lot of standards are broken or not definite enough. 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/ )
Re: [MP3 ENCODER] CRC on MP3
Thanx very much ! That was the kind of info I was looking for. Even the ISO spec are available :) (not sure if it's their initial form) And sadly it seems that the CRC is much more complicated than I thought (just scanning a part of the header and the whole audio encoding). - Original Message - From: "Albert Faber" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 17, 2000 12:54 AM Subject: Re: [MP3 ENCODER] CRC on MP3 > Look at Gabriel's home page http://www.mp3-tech.org/ , see section > programmer's corner > > Albert > > http://www.cdex.n3.net/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3 compressed wav files
It's called Rename (dev code is F2) on Windows. You just rename your mp3 files with a wav extension. - Original Message - From: "Sterling Windmill" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 17, 2000 8:53 PM Subject: [MP3 ENCODER] mp3 compressed wav files > Anyone know of any utilities that will convert an mp3 into an mp3 compressed > wav file? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi PCM file coding and decoding
> From: "DataFlow" <[EMAIL PROTECTED]> > > then why do all encoders add this gap? > anyone knows this? Check the archives of the list: Mark Taylor wrote quite a lengthy explanation a while back. Maybe it's on the web site too. IIRC, the delay at the beginning can be removed, but would result in attenuation (decrease in volume) in the first frame. The delay at the end is unavoidable unless you have some way of transmitting the exact length of the original file. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] MPEG audio decoder compliance
Hello Gabriel, Thursday, August 17, 2000, 5:59:46 PM, you wrote: >> RL> If you can point me to a specific implementation I can try to test it >> RL> directly. The only requirement I have is that the implementation GB> support some >> RL> way of saving the decoded output to a file (e.g. WAV). >> >> Would be great: http://www.daansystems.com/coolplayer >> GB> It's useless as this player uses Xaudio GB> Gabriel Bouvigne - France ?? The point was that the test says Xaudio is perfect, and I can clearly hear something is wrong. The link was provided to test if the xaudio test was ok, or the implementation in coolplayer is ok. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Xing header problem
I've been having problems with lame `randomly' writing `incorrect' Xing headers. I finally figured out that it's not random (it's my fault) and lame isn't writing incorrect Xing info, but no info at all. What's been going on? I start up lame lame -k -v -V 0 -b 160 -B 320 foo.wav foo.mp3 and then while lame is still compressing, do an mv foo.mp3 bar.mp3 lame is obviously doing the right thing by putting in a LAME block in place of the Xing block so it can come back later and fill it in with the correct info, but it seems lame is closing the mp3 when it is finished compressing and then re-opening it to write the Xing info. Now, while I will admit this might be a "don't do that" type of thing, I still feel that this is a bug as lame should be more robust than that. I guess not enough people rip CDs by hand to notice this :/. In the meantime, I'll change my habits, but I thought this problem should be reported. Bill -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3 compressed wav files
I realize that it will play if renamed, but I need an actual wav header to be present, I know these utilities exist, I just can't seem to find one. >From: "Steve Lhomme" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: Re: [MP3 ENCODER] mp3 compressed wav files >Date: Thu, 17 Aug 2000 22:23:31 +0200 > >It's called Rename (dev code is F2) on Windows. > >You just rename your mp3 files with a wav extension. > >- Original Message - >From: "Sterling Windmill" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Thursday, August 17, 2000 8:53 PM >Subject: [MP3 ENCODER] mp3 compressed wav files > > > > Anyone know of any utilities that will convert an mp3 into an mp3 >compressed > > wav file? > >-- >MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3 compressed wav files
Sterling Windmill schrieb am Don, 17 Aug 2000: > I realize that it will play if renamed, but I need an actual wav header to > be present, I know these utilities exist, I just can't seem to find one. You may look at dailymp3.com ? Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Xing header problem
Bill Currie schrieb am Don, 17 Aug 2000: > I've been having problems with lame `randomly' writing `incorrect' Xing > headers. I finally figured out that it's not random (it's my fault) and lame > isn't writing incorrect Xing info, but no info at all. What's been going on? I > start up lame > > lame -k -v -V 0 -b 160 -B 320 foo.wav foo.mp3 > > and then while lame is still compressing, do an > > mv foo.mp3 bar.mp3 > > lame is obviously doing the right thing by putting in a LAME block in place of > the Xing block so it can come back later and fill it in with the correct info, > but it seems lame is closing the mp3 when it is finished compressing and then > re-opening it to write the Xing info. > > Now, while I will admit this might be a "don't do that" type of thing, I still > feel that this is a bug as lame should be more robust than that. I guess not > enough people rip CDs by hand to notice this :/. In the meantime, I'll change > my habits, but I thought this problem should be reported. > > Bill Hm, I think this is not right in LAME. Maybe there are reasons for closing and reopening the stream, but I don't see any. Further I fear that in case of ID3v2 tags the filesize is not correctly calculated. This needs some attention! Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Xing header problem
On Thu, Aug 17, 2000 at 11:24:14PM +0200, Robert Hegemann wrote:
> Bill Currie schrieb am Don, 17 Aug 2000:
[Xing header garble snipped]
> Hm, I think this is not right in LAME. Maybe there are reasons for closing
> and reopening the stream, but I don't see any.
The only reason I can see so far (I've been browsing the code looking for
open/close calls) is either simplicity, ad hoc modifications, or a combination
of the two. Of coures, I could be missing something (like possibly the
inability to seek under certain circumstances).
> Further I fear that in case
> of ID3v2 tags the filesize is not correctly calculated.
Ouch :/ Well, I'll leave this to those with more knowledge:)
> This needs some attention!
Thanks. Though I've found a work around ("don't do that":), this has been
giving me problems for 2 weeks and has obviously been there for a while. The
only reason I figured out what was going on was I decided to run 16 lame
processes at once (as a lark), remove the .wav files and rename the .mp3 files
to their final names. I wound up with 16 25+ minute songs (according to xmms).
Uh-huh, yeah, right, 400 minutes of music on one cd? I don't think so:).
Now all I need is to find (or write) a program to create a correct Xing
header. I really don't feel like re-ripping all those cds (about 30).
Bill
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] The best decoders
David Starks-Browning wrote: > I read on the in_mpg123 web page that it doesn't support streaming. > Could this be your problem? I'm not streaming, simply playing a large playlist containing 6 days of music. Occasionally I move or delete an MP3 while it still exists in the playlist and that's when it fails. I can't use the fhg plug-in either because it doesn't read VBR headers and I need to know the length of every song. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] MPEG audio decoder compliance
> RL> If you can point me to a specific implementation I can try to test it > RL> directly. The only requirement I have is that the implementation support > RL> some way of saving the decoded output to a file (e.g. WAV). > > Would be great: http://www.daansystems.com/coolplayer I tested CoolPlayer and added it to the list of results: http://www.mars.org/home/rob/proj/mpeg/compliance/ What's interesting is that CoolPlayer's Layer II results don't match Xaudio's. But otherwise, Layer I and Layer III do, although FWIW the output is not bit-for-bit precisely the same. One thing to consider is that the compliance test data only sweeps frequencies up to 10kHz, so unfortunately any bizarre behavior above this would not be detected. > maybe to be sure you can capture the output with totalrecorder. This > way you can also assure that the output is the same as the .wav > writer. What is totalrecorder? -- Rob Leslie [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
