twolame-discuss Mailing List for TwoLAME
MPEG-Audio Layer 2 (MP2) encoder
Status: Beta
Brought to you by:
nhumfrey
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(8) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
(11) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(14) |
Nov
(3) |
Dec
(4) |
2007 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
(3) |
Feb
(1) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2015 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Nicholas H. <nj...@ae...> - 2019-10-11 22:34:30
|
Hello, I have just released TwoLAME version 0.4.0. It is available for download from SourceForge: https://downloads.sourceforge.net/twolame/twolame-0.4.0.tar.gz And also GitHub: https://github.com/njh/twolame/releases/tag/0.4.0 Changes in this release are: - Added free format encoding (now up to 450 kbps) - Added DAB utility methods for ScF-CRC handling - Added `twolame_get_original()` and `twolame_set_original()` - Added `twolame_get_extension()` and `twolame_set_extension()` - Bundled .spec file in tarball for building RPM for twolame - Make libsndfile dependency (and therefore the frontend) optional - Fixed VBR encoding - Fixed setting for error protection flag - Fixed padding bugs - Fixed scaling of floating point input source through libsndfile - Removed `slotinfo` global variables to fix a thread safety bug - Switched to handling reading from STDIN using libsndfile - Improvements to the Windows build process - Compiler and Valgrind warning fixes - Various other fixes and enhancements Thanks to Elio Blanca in particular for a large number of the contributions to this release but also: - Aleksander Morgado - Daniel Mierswa - Darrell Walisser - James Almer - Jörgen Scott - Kieran Kunhya - Leo Famulari - Sebastian Ramacher - Stephen Hutchinson - Vincent Torri The gap between releases is increasing! I am going to be removing some deprecated functions in the next release, so the release version number is likely to be 1.0. Lets hope it doesn't take me longer than 8 years this time... nick. |
From: Elio B. <ebl...@us...> - 2016-12-21 23:40:02
|
I want to read a layerII frame and skip all the bit allocation/scalefactors/samples stuff and getting straight to the ancillary bits. I know in layerIII one can read the side information block and get the backpointer, then the size of part2+part3 (scalefactors/huffman codes/whatever) and jump to the ancillary bits. Is there a simple way for doing this in layerII ? Elio |
From: Richard A. <ri...@au...> - 2015-01-03 20:00:03
|
On Sat, 03 Jan 2015 12:27:36 -0700 dave allen <da...@re...> wrote: > wow. indeed. it's been a while. forgot i was even on it. > > i like libmad (Mpeg Audio Decoder). But (as this is VOIP), it's about the slowest decoder out there, so mpg123 or ffmpeg are likely to be quicker if that matters. I don't believe there is much in the sound quality these days. I presume you have good reason for doing VOIP with a legacy codec like MP2, rather than something current (lower latency and higher quality) like Opus! Richard |
From: dave a. <da...@re...> - 2015-01-03 19:40:45
|
wow. indeed. it's been a while. forgot i was even on it. i like libmad (Mpeg Audio Decoder). dave On 1/3/2015 10:31 AM, Thomas Auge wrote: > Hello list, > > is anyone still reading this? :) > > I'm looking to use TwoLame in a VoIP application and was wondering which decoder you'd recommend to combine with it? > > Thanks, > > Thomas > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > TwoLAME-discuss mailing list > Two...@li... > https://lists.sourceforge.net/lists/listinfo/twolame-discuss > |
From: Thomas A. <au...@vi...> - 2015-01-03 17:48:52
|
Hello list, is anyone still reading this? :) I'm looking to use TwoLame in a VoIP application and was wondering which decoder you'd recommend to combine with it? Thanks, Thomas |
From: Nicholas J H. <nj...@ae...> - 2012-11-11 19:17:35
|
Hello Thomas, I'm afraid I don't have Windows, so I have been unable to run your test. I managed to uncompress your RAR archive but unable to get any further than that - it doesn't seem to be written in C? To verify your claim that TwoLame is not thread-safe, I have written a test programme in C and uploaded it here: https://gist.github.com/4055841 It encodes 20 files from raw 16-bit samples to MP2 and MD5-hashes the result to check integrity. The encodes are started after a random delay. I have run it successfully on Mac OS X and Debian/Linux without any errors or crashes. I suspect that if there is a problem on Windows, then there is a Windows specific non-thread-safe system call being called, but I am afraid that I have no idea what that might be. If you can provide any more information about what you might think is wrong with TwoLAME, then I can take a look but at the moment, I don't have a lot to go on. Would you be able to compile my test on Windows and see if you experience the same problem? Thanks, nick. > > Hi, > > The first bullet point in the twolame encoder feature list is "Fully > thread-safe". > Unfortunately that's a false statement. > To prove it I wrote a simple Windows Forms Application that encodes 8 > *.wav files via a thread pool. > I could however pinpoint the issue to redirecting the error output. > The bug occurs if there's no logging but doesn't if there is. > > If you want to have a look yourself download the application's source code > from here: > http://www.tomwolle.de/c++/src/twolame_encoder_mt_test.rar > > Simply compile the x64 Debug configuration and start the process via the > "Go" button. > The "LogOutput" checkbox allows for quickly switching between the 2 > debugging states. > The resulting *.mp2 files will be located at the source file's location in > the "source" folder. > If the bug occurs corresponding *.mp2 files will be missing and a > "twolame.exe.stackdump" file will get created under the > "...\bin\x64\Debug" directory. > > Danke, > Thomas |
From: Thomas W. <wol...@ms...> - 2012-10-08 07:54:11
|
Hi, The first bullet point in the twolame encoder feature list is "Fully thread-safe". Unfortunately that's a false statement. To prove it I wrote a simple Windows Forms Application that encodes 8 *.wav files via a thread pool. I could however pinpoint the issue to redirecting the error output. The bug occurs if there's no logging but doesn't if there is. If you want to have a look yourself download the application's source code from here: http://www.tomwolle.de/c++/src/twolame_encoder_mt_test.rar Simply compile the x64 Debug configuration and start the process via the "Go" button. The "LogOutput" checkbox allows for quickly switching between the 2 debugging states. The resulting *.mp2 files will be located at the source file's location in the "source" folder. If the bug occurs corresponding *.mp2 files will be missing and a "twolame.exe.stackdump" file will get created under the "...\bin\x64\Debug" directory. Danke, Thomas |
From: Thomas W. <wol...@ms...> - 2012-04-13 11:16:46
|
Hi guys, I'm not sure how active development around the twolame encoder these days is but I thought I post this info anyway. In our production environment we're working heavily with this encoder so far without any issues, except for this one file. I uploaded an archive file to the link at the bottom of this email that contains everything for a simple repro case. Simply dragndrop the "short.wav" onto the "encode_vbr.bat" script. For some unclear reason that process produces a faulty output file. By faulty I mean several standard player cannot playback that file. Once I remove the "-V -5" option it works. Is that issue known if not have fun fixing! :) http://www.tomwolle.de/files/mp2-encoder.rar Cheers, Tom |
From: dave a. <da...@re...> - 2012-03-02 23:02:49
|
tried the pgm on two other win7 computers, a dual-core and 4-core. they both had errors, tho the 4-core had a lot more, even when only running 2 cores (2 conversion threads). so it still may be a system problem. but splitting the jobs up an doing the 44100 conversions first, then the 48000 is working very well, so i'm just going to stick with that for now. unless perhaps you saw something nasty in my code snippet. if you wish to pursue this, i can help, send you the pgm, do more testing, etc. let me know. but for now, "i'm good". many thanks. dave allen On 3/1/2012 4:22 AM, Nicholas J Humfrey wrote: > Hello, > > This morning, I went through the code again and was unable to find any > other global / static variables that might be causing this. Very odd. > There are lots of static consts, and a couple of static lookup tables but > they aren't affected by the encoding parameters. There is one more think > that I am planning to check. > > I am sure you are, but just double checking - are you calling > twolame_init() and storing it in a separate variable for each thread? Once > an instance it created, it is unwise to change encoding parameters. > > Something to check is that you get the same behaviour for all the > psychoacoustic models - that might help track down the problem. > > Sorry I couldn't be of more help. > > nick. > > >> thanks for your response. yes. i have no problem when running >> sequentially. i have also modified my pgm to do all the 44100 >> conversions first, then the 48000, and have seen no problem yet with >> that, even with 8 jobs running at once (8 cores). >> >> it is a very sneaky thing. only shows up in every 8-12 conversions, and >> only once per file. >> >> i'm not too concerned. doing the 44100 and 48000 conversions separately >> is working, so don't spend too much time on it. i can strip out that >> part of the code and send it to you to test if you want. >> >> it still could be a system thing, throwing crazy bytes around, and it >> just doesn't show up because all the frames are the same size when doing >> the sample rates separately. >> >> and i haven't tried it on other systems. i will do that to see if it >> follows to another system. i have a 4-core win7 i can try it on. let me >> do that first, and i'll report back. >> >> dave allen >> colorado >> >> >> On 2/29/2012 4:34 PM, Nicholas Humfrey wrote: >>> Hello, >>> >>> One of the things I worked hard on, when forking tooLAME to become >>> TwoLAME, was making it thread-safe. I am pretty sure I managed to remove >>> all the global and static variables, and as the threads don't interact >>> with each other. So I am not sure what could be causing the problem. >>> >>> Are you sure that it is threading related and not just a more general >>> bug? Does the same code run sequentially all work fine? >>> >>> >>> nick. >>> >>> >>> On 28 Feb 2012, at 05:01, dave allen wrote: >>> >>>> hi folks. the twolame encoder is really, really slick. but i have a >>>> problem. we got new computers with 8 cores, so i have split an encoding >>>> pgm up into threads to run in parallel. but i'm getting some random >>>> errors - mp2 frames not aligned properly. >>>> >>>> (win7, i built the dll using your vc++ project file and visual c++ >>>> 2010) >>>> >>>> what really makes the problem apparent is i'm encoding some files at >>>> 44100 and others at 48000 at the same time. frame sizes 626 and 576 >>>> respectively (192kbits, mono). my pgm to check the mp2 frames tells me >>>> how many bytes it has to skip to sync up to the next good frame, and >>>> when i'm encoding 44100 (frame size 626) it will report a bad frame, >>>> and >>>> 576 bytes to sync up to the next frame. so somehow 576 bytes have been >>>> inserted where they don't belong. (and they do not have a valid frame >>>> header.) when encoding 48000 (frame size 576) i'll see a bad frame, >>>> then >>>> 50 bytes to sync up (626-675=50). so 626 bytes have been inserted. >>>> (without a valid frame header.) >>>> >>>> the resulting bad mp2 files for 48000 are 50 bytes bigger than a >>>> "correct" file, and for the 44100 files, the bad files are 50 bytes >>>> smaller, i presume from putting a >>>> >>>> i know multi-threading is quite the can of worms, but it may become >>>> more >>>> common as they add cores to cpus rather than speed -- until the next >>>> speed breakthrough. just wondering what i might check on my end to make >>>> sure i'm doing this right. it all works fine when i do one file at a >>>> time, or when i do all the 48000 conversions, then the 44100. that's >>>> what i'll do until i figure something else out. >>>> >>>> ain't threads wunnuful ?? >>>> >>>> thanks. >>>> dave allen >>>> colorado >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Keep Your Developer Skills Current with LearnDevNow! >>>> The most comprehensive online learning library for Microsoft developers >>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>>> MVC3, >>>> Metro Style Apps, more. Free future releases when you subscribe now! >>>> http://p.sf.net/sfu/learndevnow-d2d >>>> _______________________________________________ >>>> TwoLAME-discuss mailing list >>>> Two...@li... >>>> https://lists.sourceforge.net/lists/listinfo/twolame-discuss > > |
From: Nicholas J H. <nj...@ae...> - 2012-03-01 12:08:20
|
Sorry about the multiple sends of my previous message - was having network trouble. I have used objdump to check for .bss sections in the code: objdump -t libtwolame/.libs/libtwolame.a And it only found the ones I found by a manual scan: psycho_1.o: file format elf32-i386 00000000 l O .bss 00000004 init.4038 00000020 l O .bss 00002000 window.4039 psycho_3.o: file format elf32-i386 00000000 l O .bss 00000004 init.4038 00000020 l O .bss 00002000 window.4039 Not sure what else to check... nick. > Hello, > > This morning, I went through the code again and was unable to find any > other global / static variables that might be causing this. Very odd. > There are lots of static consts, and a couple of static lookup tables but > they aren't affected by the encoding parameters. There is one more think > that I am planning to check. > > I am sure you are, but just double checking - are you calling > twolame_init() and storing it in a separate variable for each thread? Once > an instance it created, it is unwise to change encoding parameters. > > Something to check is that you get the same behaviour for all the > psychoacoustic models - that might help track down the problem. > > Sorry I couldn't be of more help. > > nick. > > >> thanks for your response. yes. i have no problem when running >> sequentially. i have also modified my pgm to do all the 44100 >> conversions first, then the 48000, and have seen no problem yet with >> that, even with 8 jobs running at once (8 cores). >> >> it is a very sneaky thing. only shows up in every 8-12 conversions, and >> only once per file. >> >> i'm not too concerned. doing the 44100 and 48000 conversions separately >> is working, so don't spend too much time on it. i can strip out that >> part of the code and send it to you to test if you want. >> >> it still could be a system thing, throwing crazy bytes around, and it >> just doesn't show up because all the frames are the same size when doing >> the sample rates separately. >> >> and i haven't tried it on other systems. i will do that to see if it >> follows to another system. i have a 4-core win7 i can try it on. let me >> do that first, and i'll report back. >> >> dave allen >> colorado >> >> >> On 2/29/2012 4:34 PM, Nicholas Humfrey wrote: >>> Hello, >>> >>> One of the things I worked hard on, when forking tooLAME to become >>> TwoLAME, was making it thread-safe. I am pretty sure I managed to >>> remove >>> all the global and static variables, and as the threads don't interact >>> with each other. So I am not sure what could be causing the problem. >>> >>> Are you sure that it is threading related and not just a more general >>> bug? Does the same code run sequentially all work fine? >>> >>> >>> nick. >>> >>> >>> On 28 Feb 2012, at 05:01, dave allen wrote: >>> >>>> hi folks. the twolame encoder is really, really slick. but i have a >>>> problem. we got new computers with 8 cores, so i have split an >>>> encoding >>>> pgm up into threads to run in parallel. but i'm getting some random >>>> errors - mp2 frames not aligned properly. >>>> >>>> (win7, i built the dll using your vc++ project file and visual c++ >>>> 2010) >>>> >>>> what really makes the problem apparent is i'm encoding some files at >>>> 44100 and others at 48000 at the same time. frame sizes 626 and 576 >>>> respectively (192kbits, mono). my pgm to check the mp2 frames tells me >>>> how many bytes it has to skip to sync up to the next good frame, and >>>> when i'm encoding 44100 (frame size 626) it will report a bad frame, >>>> and >>>> 576 bytes to sync up to the next frame. so somehow 576 bytes have been >>>> inserted where they don't belong. (and they do not have a valid frame >>>> header.) when encoding 48000 (frame size 576) i'll see a bad frame, >>>> then >>>> 50 bytes to sync up (626-675=50). so 626 bytes have been inserted. >>>> (without a valid frame header.) >>>> >>>> the resulting bad mp2 files for 48000 are 50 bytes bigger than a >>>> "correct" file, and for the 44100 files, the bad files are 50 bytes >>>> smaller, i presume from putting a >>>> >>>> i know multi-threading is quite the can of worms, but it may become >>>> more >>>> common as they add cores to cpus rather than speed -- until the next >>>> speed breakthrough. just wondering what i might check on my end to >>>> make >>>> sure i'm doing this right. it all works fine when i do one file at a >>>> time, or when i do all the 48000 conversions, then the 44100. that's >>>> what i'll do until i figure something else out. >>>> >>>> ain't threads wunnuful ?? >>>> >>>> thanks. >>>> dave allen >>>> colorado >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Keep Your Developer Skills Current with LearnDevNow! >>>> The most comprehensive online learning library for Microsoft >>>> developers >>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>>> MVC3, >>>> Metro Style Apps, more. Free future releases when you subscribe now! >>>> http://p.sf.net/sfu/learndevnow-d2d >>>> _______________________________________________ >>>> TwoLAME-discuss mailing list >>>> Two...@li... >>>> https://lists.sourceforge.net/lists/listinfo/twolame-discuss >>> >> > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > TwoLAME-discuss mailing list > Two...@li... > https://lists.sourceforge.net/lists/listinfo/twolame-discuss > |
From: Nicholas J H. <nj...@ae...> - 2012-03-01 11:22:55
|
Hello, This morning, I went through the code again and was unable to find any other global / static variables that might be causing this. Very odd. There are lots of static consts, and a couple of static lookup tables but they aren't affected by the encoding parameters. There is one more think that I am planning to check. I am sure you are, but just double checking - are you calling twolame_init() and storing it in a separate variable for each thread? Once an instance it created, it is unwise to change encoding parameters. Something to check is that you get the same behaviour for all the psychoacoustic models - that might help track down the problem. Sorry I couldn't be of more help. nick. > thanks for your response. yes. i have no problem when running > sequentially. i have also modified my pgm to do all the 44100 > conversions first, then the 48000, and have seen no problem yet with > that, even with 8 jobs running at once (8 cores). > > it is a very sneaky thing. only shows up in every 8-12 conversions, and > only once per file. > > i'm not too concerned. doing the 44100 and 48000 conversions separately > is working, so don't spend too much time on it. i can strip out that > part of the code and send it to you to test if you want. > > it still could be a system thing, throwing crazy bytes around, and it > just doesn't show up because all the frames are the same size when doing > the sample rates separately. > > and i haven't tried it on other systems. i will do that to see if it > follows to another system. i have a 4-core win7 i can try it on. let me > do that first, and i'll report back. > > dave allen > colorado > > > On 2/29/2012 4:34 PM, Nicholas Humfrey wrote: >> Hello, >> >> One of the things I worked hard on, when forking tooLAME to become >> TwoLAME, was making it thread-safe. I am pretty sure I managed to remove >> all the global and static variables, and as the threads don't interact >> with each other. So I am not sure what could be causing the problem. >> >> Are you sure that it is threading related and not just a more general >> bug? Does the same code run sequentially all work fine? >> >> >> nick. >> >> >> On 28 Feb 2012, at 05:01, dave allen wrote: >> >>> hi folks. the twolame encoder is really, really slick. but i have a >>> problem. we got new computers with 8 cores, so i have split an encoding >>> pgm up into threads to run in parallel. but i'm getting some random >>> errors - mp2 frames not aligned properly. >>> >>> (win7, i built the dll using your vc++ project file and visual c++ >>> 2010) >>> >>> what really makes the problem apparent is i'm encoding some files at >>> 44100 and others at 48000 at the same time. frame sizes 626 and 576 >>> respectively (192kbits, mono). my pgm to check the mp2 frames tells me >>> how many bytes it has to skip to sync up to the next good frame, and >>> when i'm encoding 44100 (frame size 626) it will report a bad frame, >>> and >>> 576 bytes to sync up to the next frame. so somehow 576 bytes have been >>> inserted where they don't belong. (and they do not have a valid frame >>> header.) when encoding 48000 (frame size 576) i'll see a bad frame, >>> then >>> 50 bytes to sync up (626-675=50). so 626 bytes have been inserted. >>> (without a valid frame header.) >>> >>> the resulting bad mp2 files for 48000 are 50 bytes bigger than a >>> "correct" file, and for the 44100 files, the bad files are 50 bytes >>> smaller, i presume from putting a >>> >>> i know multi-threading is quite the can of worms, but it may become >>> more >>> common as they add cores to cpus rather than speed -- until the next >>> speed breakthrough. just wondering what i might check on my end to make >>> sure i'm doing this right. it all works fine when i do one file at a >>> time, or when i do all the 48000 conversions, then the 44100. that's >>> what i'll do until i figure something else out. >>> >>> ain't threads wunnuful ?? >>> >>> thanks. >>> dave allen >>> colorado >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>> MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-d2d >>> _______________________________________________ >>> TwoLAME-discuss mailing list >>> Two...@li... >>> https://lists.sourceforge.net/lists/listinfo/twolame-discuss >> > |
From: Nicholas J H. <nj...@ae...> - 2012-03-01 11:22:46
|
Hello, This morning, I went through the code again and was unable to find any other global / static variables that might be causing this. Very odd. There are lots of static consts, and a couple of static lookup tables but they aren't affected by the encoding parameters. There is one more think that I am planning to check. I am sure you are, but just double checking - are you calling twolame_init() and storing it in a separate variable for each thread? Once an instance it created, it is unwise to change encoding parameters. Something to check is that you get the same behaviour for all the psychoacoustic models - that might help track down the problem. Sorry I couldn't be of more help. nick. > thanks for your response. yes. i have no problem when running > sequentially. i have also modified my pgm to do all the 44100 > conversions first, then the 48000, and have seen no problem yet with > that, even with 8 jobs running at once (8 cores). > > it is a very sneaky thing. only shows up in every 8-12 conversions, and > only once per file. > > i'm not too concerned. doing the 44100 and 48000 conversions separately > is working, so don't spend too much time on it. i can strip out that > part of the code and send it to you to test if you want. > > it still could be a system thing, throwing crazy bytes around, and it > just doesn't show up because all the frames are the same size when doing > the sample rates separately. > > and i haven't tried it on other systems. i will do that to see if it > follows to another system. i have a 4-core win7 i can try it on. let me > do that first, and i'll report back. > > dave allen > colorado > > > On 2/29/2012 4:34 PM, Nicholas Humfrey wrote: >> Hello, >> >> One of the things I worked hard on, when forking tooLAME to become >> TwoLAME, was making it thread-safe. I am pretty sure I managed to remove >> all the global and static variables, and as the threads don't interact >> with each other. So I am not sure what could be causing the problem. >> >> Are you sure that it is threading related and not just a more general >> bug? Does the same code run sequentially all work fine? >> >> >> nick. >> >> >> On 28 Feb 2012, at 05:01, dave allen wrote: >> >>> hi folks. the twolame encoder is really, really slick. but i have a >>> problem. we got new computers with 8 cores, so i have split an encoding >>> pgm up into threads to run in parallel. but i'm getting some random >>> errors - mp2 frames not aligned properly. >>> >>> (win7, i built the dll using your vc++ project file and visual c++ >>> 2010) >>> >>> what really makes the problem apparent is i'm encoding some files at >>> 44100 and others at 48000 at the same time. frame sizes 626 and 576 >>> respectively (192kbits, mono). my pgm to check the mp2 frames tells me >>> how many bytes it has to skip to sync up to the next good frame, and >>> when i'm encoding 44100 (frame size 626) it will report a bad frame, >>> and >>> 576 bytes to sync up to the next frame. so somehow 576 bytes have been >>> inserted where they don't belong. (and they do not have a valid frame >>> header.) when encoding 48000 (frame size 576) i'll see a bad frame, >>> then >>> 50 bytes to sync up (626-675=50). so 626 bytes have been inserted. >>> (without a valid frame header.) >>> >>> the resulting bad mp2 files for 48000 are 50 bytes bigger than a >>> "correct" file, and for the 44100 files, the bad files are 50 bytes >>> smaller, i presume from putting a >>> >>> i know multi-threading is quite the can of worms, but it may become >>> more >>> common as they add cores to cpus rather than speed -- until the next >>> speed breakthrough. just wondering what i might check on my end to make >>> sure i'm doing this right. it all works fine when i do one file at a >>> time, or when i do all the 48000 conversions, then the 44100. that's >>> what i'll do until i figure something else out. >>> >>> ain't threads wunnuful ?? >>> >>> thanks. >>> dave allen >>> colorado >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>> MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-d2d >>> _______________________________________________ >>> TwoLAME-discuss mailing list >>> Two...@li... >>> https://lists.sourceforge.net/lists/listinfo/twolame-discuss >> > |
From: Nicholas J H. <nj...@ae...> - 2012-03-01 11:22:36
|
Hello, This morning, I went through the code again and was unable to find any other global / static variables that might be causing this. Very odd. There are lots of static consts, and a couple of static lookup tables but they aren't affected by the encoding parameters. There is one more think that I am planning to check. I am sure you are, but just double checking - are you calling twolame_init() and storing it in a separate variable for each thread? Once an instance it created, it is unwise to change encoding parameters. Something to check is that you get the same behaviour for all the psychoacoustic models - that might help track down the problem. Sorry I couldn't be of more help. nick. > thanks for your response. yes. i have no problem when running > sequentially. i have also modified my pgm to do all the 44100 > conversions first, then the 48000, and have seen no problem yet with > that, even with 8 jobs running at once (8 cores). > > it is a very sneaky thing. only shows up in every 8-12 conversions, and > only once per file. > > i'm not too concerned. doing the 44100 and 48000 conversions separately > is working, so don't spend too much time on it. i can strip out that > part of the code and send it to you to test if you want. > > it still could be a system thing, throwing crazy bytes around, and it > just doesn't show up because all the frames are the same size when doing > the sample rates separately. > > and i haven't tried it on other systems. i will do that to see if it > follows to another system. i have a 4-core win7 i can try it on. let me > do that first, and i'll report back. > > dave allen > colorado > > > On 2/29/2012 4:34 PM, Nicholas Humfrey wrote: >> Hello, >> >> One of the things I worked hard on, when forking tooLAME to become >> TwoLAME, was making it thread-safe. I am pretty sure I managed to remove >> all the global and static variables, and as the threads don't interact >> with each other. So I am not sure what could be causing the problem. >> >> Are you sure that it is threading related and not just a more general >> bug? Does the same code run sequentially all work fine? >> >> >> nick. >> >> >> On 28 Feb 2012, at 05:01, dave allen wrote: >> >>> hi folks. the twolame encoder is really, really slick. but i have a >>> problem. we got new computers with 8 cores, so i have split an encoding >>> pgm up into threads to run in parallel. but i'm getting some random >>> errors - mp2 frames not aligned properly. >>> >>> (win7, i built the dll using your vc++ project file and visual c++ >>> 2010) >>> >>> what really makes the problem apparent is i'm encoding some files at >>> 44100 and others at 48000 at the same time. frame sizes 626 and 576 >>> respectively (192kbits, mono). my pgm to check the mp2 frames tells me >>> how many bytes it has to skip to sync up to the next good frame, and >>> when i'm encoding 44100 (frame size 626) it will report a bad frame, >>> and >>> 576 bytes to sync up to the next frame. so somehow 576 bytes have been >>> inserted where they don't belong. (and they do not have a valid frame >>> header.) when encoding 48000 (frame size 576) i'll see a bad frame, >>> then >>> 50 bytes to sync up (626-675=50). so 626 bytes have been inserted. >>> (without a valid frame header.) >>> >>> the resulting bad mp2 files for 48000 are 50 bytes bigger than a >>> "correct" file, and for the 44100 files, the bad files are 50 bytes >>> smaller, i presume from putting a >>> >>> i know multi-threading is quite the can of worms, but it may become >>> more >>> common as they add cores to cpus rather than speed -- until the next >>> speed breakthrough. just wondering what i might check on my end to make >>> sure i'm doing this right. it all works fine when i do one file at a >>> time, or when i do all the 48000 conversions, then the 44100. that's >>> what i'll do until i figure something else out. >>> >>> ain't threads wunnuful ?? >>> >>> thanks. >>> dave allen >>> colorado >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>> MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-d2d >>> _______________________________________________ >>> TwoLAME-discuss mailing list >>> Two...@li... >>> https://lists.sourceforge.net/lists/listinfo/twolame-discuss >> > |
From: Nicholas J H. <nj...@ae...> - 2012-03-01 11:15:09
|
*resending to list* Hello, One of the things I worked hard on, when forking tooLAME to become TwoLAME, was making it thread-safe. I am pretty sure I managed to remove all the global and static variables, and as the threads don't interact with each other. So I am not sure what could be causing the problem. Are you sure that it is threading related and not just a more general bug? Does the same code run sequentially all work fine? nick. On 28 Feb 2012, at 05:01, dave allen wrote: > hi folks. the twolame encoder is really, really slick. but i have a problem. we got new computers with 8 cores, so i have split an encoding pgm up into threads to run in parallel. but i'm getting some random errors - mp2 frames not aligned properly. > > (win7, i built the dll using your vc++ project file and visual c++ 2010) > > what really makes the problem apparent is i'm encoding some files at 44100 and others at 48000 at the same time. frame sizes 626 and 576 respectively (192kbits, mono). my pgm to check the mp2 frames tells me how many bytes it has to skip to sync up to the next good frame, and when i'm encoding 44100 (frame size 626) it will report a bad frame, and 576 bytes to sync up to the next frame. so somehow 576 bytes have been inserted where they don't belong. (and they do not have a valid frame header.) when encoding 48000 (frame size 576) i'll see a bad frame, then 50 bytes to sync up (626-675=50). so 626 bytes have been inserted. (without a valid frame header.) > > the resulting bad mp2 files for 48000 are 50 bytes bigger than a "correct" file, and for the 44100 files, the bad files are 50 bytes smaller, i presume from putting a > > i know multi-threading is quite the can of worms, but it may become more common as they add cores to cpus rather than speed -- until the next speed breakthrough. just wondering what i might check on my end to make sure i'm doing this right. it all works fine when i do one file at a time, or when i do all the 48000 conversions, then the 44100. that's what i'll do until i figure something else out. > > ain't threads wunnuful ?? > > thanks. > dave allen > colorado > > > > > ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > TwoLAME-discuss mailing list > Two...@li... > https://lists.sourceforge.net/lists/listinfo/twolame-discuss |
From: dave a. <da...@re...> - 2012-02-28 05:01:39
|
hi folks. the twolame encoder is really, really slick. but i have a problem. we got new computers with 8 cores, so i have split an encoding pgm up into threads to run in parallel. but i'm getting some random errors - mp2 frames not aligned properly. (win7, i built the dll using your vc++ project file and visual c++ 2010) what really makes the problem apparent is i'm encoding some files at 44100 and others at 48000 at the same time. frame sizes 626 and 576 respectively (192kbits, mono). my pgm to check the mp2 frames tells me how many bytes it has to skip to sync up to the next good frame, and when i'm encoding 44100 (frame size 626) it will report a bad frame, and 576 bytes to sync up to the next frame. so somehow 576 bytes have been inserted where they don't belong. (and they do not have a valid frame header.) when encoding 48000 (frame size 576) i'll see a bad frame, then 50 bytes to sync up (626-675=50). so 626 bytes have been inserted. (without a valid frame header.) the resulting bad mp2 files for 48000 are 50 bytes bigger than a "correct" file, and for the 44100 files, the bad files are 50 bytes smaller, i presume from putting a i know multi-threading is quite the can of worms, but it may become more common as they add cores to cpus rather than speed -- until the next speed breakthrough. just wondering what i might check on my end to make sure i'm doing this right. it all works fine when i do one file at a time, or when i do all the 48000 conversions, then the 44100. that's what i'll do until i figure something else out. ain't threads wunnuful ?? thanks. dave allen colorado |
From: Elio B. <ebl...@us...> - 2012-01-09 09:19:59
|
I see when lame does joint stereo encodings, it sets all frames using jointstereo value (0x1) in the `channels' field into the mpeg header. After that, some frames get encoded as simple stereo, others as ms stereo, others as intensity stereo and such. Now, what happens with layer II? I see when twolame is asked to encode joint stereo audio, it switches between stereo and jointstereo frames, changing the `channels' field into the mpeg header. So, how does this work? Is it different from layer III? On the other hand, I didn't find other layer II encoders doing jointstereo encoding (it seems only twolame supports this), so I cannot make any assumption. Elio |
From: Elio B. <ebl...@us...> - 2012-01-09 09:11:48
|
Thank you for your quick answer! Well, I see, the twolame help just says this and when requested, padding is used indeed. I was standing in a bad assumption since lame (for example) enables it by default. Thank you again Elio Il 09/01/2012 02:04, Andrew Kuklewicz ha scritto: > Padding is an optional parameter for encoding, as it is not always desirable. > > Was the file encoded with padding on? > > - Andrew > |
From: Elio B. <ebl...@us...> - 2012-01-08 22:47:09
|
Hi, I'm Elio, I'm performing several tests on an utility tool which is able to check mpeg streams. Well, when performing analysis on an layer II file created by twolame, it reports padding is never used, so when encoding 44.1 kHz contents the actual bitrate is never reached exactly. (224 kbps files report 223.9 kbps, 192 kbps ones actually report 191.7) Can this be fixed? Thank you |
From: C V. W. <lis...@cv...> - 2011-10-03 04:42:37
|
If anyone is interested in seeing/testing the end product of how I will be using TwoLAME in a commercial app, please contact me off-list. On Jul 27, 2011, at 4:05 AM, Nicholas J Humfrey wrote: > Great, I am glad that it is working for you now. > > nick. > > > On 25 Jul 2011, at 17:40, C Van Winkle <lis...@cv...> wrote: > >> Thanks Nick, I just noticed that there's a 0.3.13 update that came out in January. The changes to how the inline functions are setup fixed the problem (when the buffer was initialized, the address of the buffer went to a bogus address like 0x4). So i'm up and running now. >> >> Also, I'm _VERY_ appreciative of the removal of the exit() calls that came in 0.3.13 as well. >> >> Cheers. >> -Charles >> |
From: Nicholas J H. <nj...@ae...> - 2011-07-27 09:47:01
|
Great, I am glad that it is working for you now. nick. On 25 Jul 2011, at 17:40, C Van Winkle <lis...@cv...> wrote: > Thanks Nick, I just noticed that there's a 0.3.13 update that came out in January. The changes to how the inline functions are setup fixed the problem (when the buffer was initialized, the address of the buffer went to a bogus address like 0x4). So i'm up and running now. > > Also, I'm _VERY_ appreciative of the removal of the exit() calls that came in 0.3.13 as well. > > Cheers. > -Charles > > > On Dec 29, 2010, at 5:42 PM, Nicholas Humfrey wrote: > >> Hi Charles, >> >> I developed twolame on a Mac, but have been running it on Linux recently. I will try and have a look at this tomorrow. >> >> nick. >> >> >> On 23 Dec 2010, at 09:55, C Van Winkle wrote: >> >>> I'm able to build on OSX 10.5 and 10.6 (i386 and x86_64 respectively), but when trying to call encode_buffer, it looks like one of the malloc calls is failing. >>> >>> I'm simply running the standard "./configure" and "make" calls to get me going. >>> >>> I've tried this with and without the osx redirection needed for malloc.h (which is in /usr/include/malloc/ on OSX). >>> >>> -Charles >>> ------------------------------------------------------------------------------ >>> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >>> to consolidate database storage, standardize their database environment, and, >>> should the need arise, upgrade to a full multi-node Oracle RAC database >>> without downtime or disruption >>> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________ >>> TwoLAME-discuss mailing list >>> Two...@li... >>> https://lists.sourceforge.net/lists/listinfo/twolame-discuss >> > > |
From: C V. W. <lis...@cv...> - 2011-07-25 17:13:46
|
Thanks Nick, I just noticed that there's a 0.3.13 update that came out in January. The changes to how the inline functions are setup fixed the problem (when the buffer was initialized, the address of the buffer went to a bogus address like 0x4). So i'm up and running now. Also, I'm _VERY_ appreciative of the removal of the exit() calls that came in 0.3.13 as well. Cheers. -Charles On Dec 29, 2010, at 5:42 PM, Nicholas Humfrey wrote: > Hi Charles, > > I developed twolame on a Mac, but have been running it on Linux recently. I will try and have a look at this tomorrow. > > nick. > > > On 23 Dec 2010, at 09:55, C Van Winkle wrote: > >> I'm able to build on OSX 10.5 and 10.6 (i386 and x86_64 respectively), but when trying to call encode_buffer, it looks like one of the malloc calls is failing. >> >> I'm simply running the standard "./configure" and "make" calls to get me going. >> >> I've tried this with and without the osx redirection needed for malloc.h (which is in /usr/include/malloc/ on OSX). >> >> -Charles >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________ >> TwoLAME-discuss mailing list >> Two...@li... >> https://lists.sourceforge.net/lists/listinfo/twolame-discuss > |
From: Nicholas H. <nj...@ae...> - 2011-01-21 21:55:56
|
Hello, I have just released TwoLAME version 0.3.13: http://downloads.sourceforge.net/twolame/twolame-0.3.13.tar.gz Changes in this release are: - Fixed documentation location (--docdir in configure) - Improvements to build system - Updated to autoconf 2.60, libtool 2.2, automake 1.10 and Doxygen 1.7.3 - Fix problem with 'extern inline' by changing them to 'static inline' - Wrote perl script to test the output of the frontend - Changed all debugging messages, writing to stdout to write to stderr - Removed calls to exit() from libtwolame. - Fix for bad copy/paste of variable assignment. - Manpage correction - Changed fopen() options to wb to fix Windows I have also moved the source code repository to GitHub: http://github.com/njh/twolame As well as the issue tracker: https://github.com/njh/twolame/issues Apologies for the three year break between releases! nick. |
From: C V. W. <lis...@cv...> - 2010-12-23 22:46:09
|
I'm able to build on OSX 10.5 and 10.6 (i386 and x86_64 respectively), but when trying to call encode_buffer, it looks like one of the malloc calls is failing. I'm simply running the standard "./configure" and "make" calls to get me going. I've tried this with and without the osx redirection needed for malloc.h (which is in /usr/include/malloc/ on OSX). -Charles |
From: Stephen S. <lp...@te...> - 2009-01-14 07:40:25
|
On Wed, 14 Jan 2009, Andrew Kuklewicz wrote: > Hello, > > Trying to install the latest 0.3.12 on my mac. > > I see no error, but I also see no 'twolame' executable - am I missing something? > I do see the simple front end, 'stwolame', but not 'twolame'. > > Below is the output from my configure, make, sudo make build. <snip> > configure: WARNING: Not building twolame frontend because libsndfile is missing. It looks like this is your problem. Hopefully, installing libsndfile will take care of it. Hope this helps! Steve |
From: Andrew K. <an...@pr...> - 2009-01-14 07:23:46
|
that was my problem. configure: WARNING: Can't find libsndfile library on your system configure: WARNING: Not building twolame frontend because libsndfile is missing. Andrew Kuklewicz |