tear-devel Mailing List for TEAR
Brought to you by:
devduck
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: <tea...@li...> - 2002-10-12 21:34:41
|
Hello everybody, I know what you're thinking, but you're wrong, it hasn't been a whole year = since the last email. To those of you who just dont care anymore, unsubscribe here http://lists.s= ourceforge.net/lists/listinfo/tear-devel. To the rest of you: big news, I f= inally found enough time to do some work. The release is at http://www.devilducky.org/tear/ . this is still a "non-st= able" release even though it works perfectly for everything I've tested it = against. Ogg, lame, and cdparanoia are completly working. cdda2wav seems to= work and bldeen and gogo should work at least as far as the id3 tags, I ha= ven't tested that yet. The release is basically the 0.9 stuff we were worki= ng on with a lot of options taken out. Taking out things dont really want o= r need allows the program to run more inteliggently, as I'm sure no one her= e will contest. The forks for the programs now happen for both the ripper a= nd the encoder. This serves two uses: it should work wonders on SMP machine= s, and it allows tear to always know the pid of it's children. I also used = this to have a clean shut down in the case of a ctrl-c or otther signal. I added the much requested support for ENCEXTRA to send more arguments to t= he encoder. Having this will allow power users to play with settings most p= eople wouldn't use and we wouldn't want to support. Supporting every settin= g would just make things too confusing for developing and using. The only parts of the program that I know need working on are vbr support, = playlist support, and the CDDB fill in stuff. I can do the vbr and cddb stu= ff, but would prefer no to do the playlist. Every attempt of mine ends up w= eird. For reasons I will explain in an upcoming paragraph these changes wil= l be in 1.0_rc2. As always suggestions and bug fixes are welcome. I still need to do almost of the documenting. I just slapped an old manfile= in the tarball and did rudimentary editing of the other docs. I will work = on these soon, unless someone else would like to be extremly helpful and lo= ved by me.=20 Packaging... oh what to say about packaging... Meikel if you're still inter= ested, you can do a .deb version of this. I no longer have access to a redh= at machine or even a machine that has rpm, so I need someone to do rpms for= me, Mark? I can help if you dont know what to do. Any other distributions = would also be appreciated of course. I have already made a gentoo ebuild. A= nd do the fact that I was on #gentoo playing with it, it has already been s= ubmitted to be included in portage, which is why we can just make any chang= es for the next release. Oh, another note. The Makefile that is included in the tarball right now is= no good. Wait a little bit and I will send another via email. I will aos u= pdate that tarball at that time. I will be making this an official release on soureforge, but not announcing= it on freshmeat. Thanks, Greg ---- T.E.A.R Encodes And Rips http://tear.sourceforge.net gpg: devilducky.org/pubkey.gpg Jabber: De...@ja... |
From: <tea...@li...> - 2001-12-02 10:42:30
|
Hi all, take a look on this release now. Looks like most of the 0.9.1 features is working again. Sure, ToDo is not short, but many of the new entries aren't catched by 0.9.1. Also I've add some checks for user input now (still not finnished). Happy testing and ripping. BTW: planned feature: use of a local CDDB "database" like xmms can use. Peter |
From: <tea...@li...> - 2001-11-27 20:28:31
|
--On Tuesday, November 27, 2001 12:23:35 PM -0500 tea...@li... wrote: >> > Make sure you leave room for two more encoders: oggenc and >> > lameogg. >> Encoders will get an "API", so no problems for others. > Cool, that's what I thought. Look into, lame is working, lameogg cannot be tested (my lame-RPM doesn't like ogg) cdda2wav is also running again. Have a look now. This release is an alpha but stable, some at-this-time non-working features. But batch ripping should work. I'm away from programming the next 2 days or so, so if someone in the meantime sends patches, I can apply them cleanly. Peter |
From: <tea...@li...> - 2001-11-27 17:27:23
|
> > I'm not afraid... > > I realize this is still apha > I'm not so fast in programming... You're fast enough :) > > Make sure you leave room for two more encoders: oggenc and lameogg. > Encoders will get an "API", so no problems for others. Cool, that's what I thought. > > MUNGING is when all of the spaces are replaced with '_'s in a > > filename. > Ok, but not used in 0.9.1 Yeah, it wasn't a high enough priroity for my to worry about yet. > Any template code available? Should only the filename be treated or > also the subdirectories? It works in 0.4.X, but you wont need that, wherever you are going to search for proper names (so people don't pass characters that will kill the shell, etc.) just replace ' ' with '_', it should also be used for subdirectories if the option is selected. > > Instead of PRGRAM_LAME_OPTIONS, you can make it > > PROGRAM_ENC_OPTIONS, that way we can have configurable options for > > all of them with no special code for each. > Hmm, options will be too different. > > 2 ways possible: > a) Each encoder get his own additional options (if not "simple mode" > is choosen) - currently implemented > > b) abstract options which are parsed per encoder, generating warnings > or errors, if encoder has not this capability. > > examples: > bitratetype=constant, bitrate=256 > bitratetype=variable, bitratemin=32, bitratemax=256 > > and so on.... > > b) is sure nicer, but more work. a) already exists, so I can add b) > to the ToDo list. I was just going to rely on the user knowing what (s)he wants to add. We can do all of the above though, have a per-encoder list of options, and a generic option for the "power user" to add even more functionality. Lame (not to mention every other encoder) supports a lot of stuff and we are not going to want to offer all of those options... this way we can support the important ones AND allow other things generically. So, both is the answer? > the filename/fileform of the playlist. I/We need to get > > a good working form for playlist... the 0.4.X code was barely > > functional. > Does this mean that sample code is found in 0.4.x? NO! I don't want anything to do with that particular piece of code, all it does is make a file and put in the full path name to the mp3, of course that's all a playlist is, but we ne3ed to add things like appending to existing files, etc. Greg ---- T.E.A.R Encodes And Rips http://tear.sourceforge.net |
From: <tea...@li...> - 2001-11-27 17:08:43
|
--On Tuesday, November 27, 2001 10:37:44 AM -0500 tea...@li... wrote: > I'm not afraid... > I realize this is still apha I'm not so fast in programming... > Make sure you leave room for two more encoders: oggenc and lameogg. Encoders will get an "API", so no problems for others. > MUNGING is when all of the spaces are replaced with '_'s in a > filename. Ok, but not used in 0.9.1 Any template code available? Should only the filename be treated or also the subdirectories? > Instead of PRGRAM_LAME_OPTIONS, you can make it > PROGRAM_ENC_OPTIONS, that way we can have configurable options for > all of them with no special code for each. Hmm, options will be too different. 2 ways possible: a) Each encoder get his own additional options (if not "simple mode" is choosen) - currently implemented b) abstract options which are parsed per encoder, generating warnings or errors, if encoder has not this capability. examples: bitratetype=constant, bitrate=256 bitratetype=variable, bitratemin=32, bitratemax=256 and so on.... b) is sure nicer, but more work. a) already exists, so I can add b) to the ToDo list. the filename/fileform of the playlist. I/We need to get > a good working form for playlist... the 0.4.X code was barely > functional. Does this mean that sample code is found in 0.4.x? Peter |
From: <tea...@li...> - 2001-11-27 15:41:33
|
> Hi, > > see here ftp://ftp.bieringer.de/pub/tear/ > > Current status: option parsing, CDDB_get and ripping with cdparanoia > is working again - not more is tested. > > See ToDo/ChangeLog for more. > > Don't wonder about the many debug lines...and hopefully also be not > afraid about the coding stye changes. I'm not afraid... I realize this is still apha so here's some "reminders" :) Make sure you leave room for two more encoders: oggenc and lameogg. In the $options_define_list: MUNGING is when all of the spaces are replaced with '_'s in a filename. STEP can be removed, I don't like the feature it represents. ERROR is the return code from the system('...') calls. It's very useful in seeing if there was an error, but it really doesn't have to be global. MP3DIR & WAVDIR have always been located in "mp3/..." not "~/mp3/...", plus you'll probably have to parse the ~ into $ENV{HOME} Instead of PRGRAM_LAME_OPTIONS, you can make it PROGRAM_ENC_OPTIONS, that way we can have configurable options for all of them with no special code for each. PLAYLIST is the filename/fileform of the playlist. I/We need to get a good working form for playlist... the 0.4.X code was barely functional. Also we can keep sending bug reports to me, unless you really want to recieve those messages. Some are quite fun. Greg ---- T.E.A.R Encodes And Rips http://tear.sourceforge.net |
From: <tea...@li...> - 2001-11-27 01:09:11
|
Hi, see here ftp://ftp.bieringer.de/pub/tear/ Current status: option parsing, CDDB_get and ripping with cdparanoia is working again - not more is tested. See ToDo/ChangeLog for more. Don't wonder about the many debug lines...and hopefully also be not afraid about the coding stye changes. Happy alpha testing (pls. test only already commited working steps). Peter |
From: <tea...@li...> - 2001-11-26 09:30:44
|
--On Sunday, November 25, 2001 08:58:55 PM -0500 tea...@li... wrote: > Yeah, someone just mentioned that to me. I am working on it, as > quickly as I can. Already fixed, use this diff: @@ -873,11 +969,13 @@ sub DirTree() { # print "In DirTree()\n"; - - my @dirs = split /\//, shift; + my $path = shift; + my @dirs = split /\//, $path; my $direc = ""; my $err = ""; + if (grep /^\//, $path) { $direc .= "/"; }; + foreach $i (@dirs) { if ($i) The second mentioned bug is also easy to fix ;-) @@ -296,7 +374,7 @@ my %args; # Get Program Defaults - my %defs = SetProgramDefaults(); + my %defs = ProperConfigValues(SetProgramDefaults()); # Get Conf File Settings $defs{CFILE} = DetermineConfFile("./.tearrc","$ENV{HOME}/.tearrc","/etc/tearrc","/et c/tear.conf"); > I do however have some requests for your impending project: > - I would like the new code to be more based on 0.9.0 then 0.4/0.5 Sure, will start from 0.9.1 > since there is a lot in there that I do like. Including the -debug > tracing and the multitasking capability. (You may also want to keep > the cddb code base since it works quite well) I really don't want to rewrite "feature" code, only the control-flow code. > - Frequent updates, once you get your new code base started I would > like to see a lot of updates, if they seem to run I will package > them (gz/bz2) and release them. No problem for me, I will create a subdirectory on my ftp server and release tar balls as often I had finish some work. So everyone can run diffs against previous version. Internally I'm using cvs (as newbie...). >> longer: >> * clean continue after interrupting, short cut modes for testing > Hmm, I've been facing the probelms of adding this type of suuport > without adding a lot more confusion to the code, but heaven knows > it would be useful. The way I do most testing now is to comment out > the actual system call, see how tear runs and then one by one run > the calls (from .tear-debug' and make sure thay all do what I would > expect of them. It's a PITA. Therefore: bitwise selectable DEBUG handling, makes life easier. >> If ok, I'll take version number 1.0.0 for starting ;-) >> If not ok, I can call it "tearng" (tear new generation), starting >> on 0.0.1 > no, lets leave 0.9.X to be the pre-development versions of 1.0, > until it gets further along and then move the code to 1.0/1.1 > In other words, take over 0.9.X; It doesn't matter if all of the > numbers correspond to the same line of thinking since it is a > development line anyway and everyone who should care is reading > (skimming, I imagine) this right now. Ok, use 0.9.2.x for the first next ones. BTW: for coding syntax TAB 8 will be used (I've tried for other projects lower, but more conflicts than nice code....) Peter |
From: <tea...@li...> - 2001-11-26 02:02:43
|
Hi all, > 1) leading / on paths are not handled, treated as relative (split > problem) Yeah, someone just mentioned that to me. I am working on it, as quickly as I can. > 2) VERBOSE from defaults is not mapped and therefore overwriting > config value NOISE Yeah, a lot of that stuff is not yet mapped correctly, I thought I mentioned that in the notes, if not I simply forgot to mention it I knew it happened. There are also several other similar "errors" that are really just incomplete code. > I've tried to implement some of my 0.5.9.specialedition features and > some failure catchup code. Believe it or not, most of your special edition features are on my list for 0.9.1, especially changing the PWD for WAVTMPDIR etc... There a few other things on my list like, bladeenc, ID3v2, and a new man file as well. I also realize that I tend to make more promises for the next version than I keep :) > So I have some questions: > > A) is there any newer code available than 0.9.0 where already a > redesign was started? Included is my current "test" copy, this is not the latest but it is the best that I have. I believe it has updated "debug" handling to try and make it clearer, it has the beginnings of looking for program errors and exiting, etc. but not too much... > B) if not, I'm close to do a complete redesign, because I want to use > tear in the future, but I really miss my specialedition features. > > If no redesign is currently started, I will do so, let's say until > new year, starting next week. It is ok, I would love the "help." I have this PalmOS project I was thinking of starting and I could use the time to research/start it. ** I will probably get bored or in over my head quite quickly, so don't worry :) ** I do however have some requests for your impending project: - I would like the new code to be more based on 0.9.0 then 0.4/0.5 since there is a lot in there that I do like. Including the -debug tracing and the multitasking capability. (You may also want to keep the cddb code base since it works quite well) - Frequent updates, once you get your new code base started I would like to see a lot of updates, if they seem to run I will package them (gz/bz2) and release them. That way I wont lose track of what you are doing while I answer questions about bugs/feature requests. (The actual release can be decided for each update, so dont worry about making sure that the code actually works all of the time. It's mostly about me seeing where the new development is occuring) - Try not to break old standards this time... 0.9.0/1 looks for both : and = and that is how we can both win (Probably only one other person on this list will understand that one) If you're unsure if there is a standard ask, I will try answer right away, that's one thing I do know well :) - Use Mpeg::Info, or whatever it is that 0.9.0 supports, this is very important since: it is Perl (always nice), it is in current development (more than we can say for id3tool), it supports ID3v2 (or so I am told), and because I said so. > Missing and "want to implement" features: > > shorter: > * clarify code and settings handling > * bitwise selectable debug code to get clearer, what's going on > * WAVTMPDIR to store ripped wav files on different dir > * catchup as many as can failures due running external programs, file > system and others > * add configurable options for compressors (e.g. special lame options) Sounds like a good list, actaully it's almost like my list... > longer: > * clean continue after interrupting, short cut modes for testing Hmm, I've been facing the probelms of adding this type of suuport without adding a lot more confusion to the code, but heaven knows it would be useful. The way I do most testing now is to comment out the actual system call, see how tear runs and then one by one run the calls (from .tear-debug' and make sure thay all do what I would expect of them. It's a PITA. > notbreaking: > * current config style should be not broken (hopefully) We certainly hope so :) > If ok, I'll take version number 1.0.0 for starting ;-) > If not ok, I can call it "tearng" (tear new generation), starting on > 0.0.1 no, lets leave 0.9.X to be the pre-development versions of 1.0, until it gets further along and then move the code to 1.0/1.1 In other words, take over 0.9.X; It doesn't matter if all of the numbers correspond to the same line of thinking since it is a development line anyway and everyone who should care is reading (skimming, I imagine) this right now. > Developing scenario: Red Hat Linux 7.2 + cdparanoia + lame > So if someone agrees for alpha testing, other scenarios will be > welcome. I will be adding Slackware 8.0 (Linux 2.4.10 ac12) + all open source supported programs (cdparanoia, cdda2wav, lame, bladence, oggenc, etc.) But of course if anyone else wants to specialize in any particualt beta test; it will just help us all out, especially me :) > Peter Greg ---- T.E.A.R Encodes And Rips http://tear.sourceforge.net |
From: <tea...@li...> - 2001-11-25 14:09:46
|
Hi, after new installation of my "tear" server I've tried 0.9.0. Beyond the two bugs I've found: 1) leading / on paths are not handled, treated as relative (split problem) 2) VERBOSE from defaults is not mapped and therefore overwriting config value NOISE I've tried to implement some of my 0.5.9.specialedition features and some failure catchup code. But I feel now, that this is not possible in 0.9.0, the code is still really not very nice (means also sometimes terrible) and sometimes not cleary designed - sorry. So I have some questions: A) is there any newer code available than 0.9.0 where already a redesign was started? B) if not, I'm close to do a complete redesign, because I want to use tear in the future, but I really miss my specialedition features. If no redesign is currently started, I will do so, let's say until new year, starting next week. Missing and "want to implement" features: shorter: * clarify code and settings handling * bitwise selectable debug code to get clearer, what's going on * WAVTMPDIR to store ripped wav files on different dir * catchup as many as can failures due running external programs, file system and others * add configurable options for compressors (e.g. special lame options) longer: * clean continue after interrupting, short cut modes for testing notbreaking: * current config style should be not broken (hopefully) If ok, I'll take version number 1.0.0 for starting ;-) If not ok, I can call it "tearng" (tear new generation), starting on 0.0.1 Comments? Developing scenario: Red Hat Linux 7.2 + cdparanoia + lame So if someone agrees for alpha testing, other scenarios will be welcome. Peter |
From: <tea...@li...> - 2001-11-02 15:27:57
|
Hello Everybody! As you may or may not have noticed I finally released new versions of tear. There's nothing special about the 0.4.6 release except that it actually works. The 0.9.0 version is the one we were all working on for so long... the thing I think is most needed is getting support back all of the features that 0.4.x had. Well maybe not all... I dont intend on bringing back the --step stuff, and playlist support just needs started over... in fact let's pretend that never existed. I have included here what will become tear-0.9.1 (it's not quite ready but it runs), a spec file that most of you wont care about, and the current Makefile. You all know what to do with the tear file... I hope. The spec file is basically only for one of you, but anyone who wants to an look at it, whatever floats your boat... The Makefile, however, is just a gnereal plea for help. I want it to basically do what it does now, be more complaint with DEB and RPM, accept shell changes (like installing in /usr/ insteado /usr/local/), and other crap like that. I am no good at such things, hence the real simple original Makefile that one person actually wrote me an amil and laughed at. The other thing I would like to do is copy README, Release, etc. into /usr/local/doc/tear/, whcih we aren't doing at all right now, but should be. Anyone like man files? I am willing to type up a new manfile text if someone is willing to put it in the correct form. For that matter if anyone wants to do any documentation upgrading I will be overjoyed. To get the new tear to work, you will need a slightly different configuration than for 0.4.x, I dont have a corresponding -require yet, but, soon. Like today, I promise. If you dont want this list anymore tell me, and I will sadly remove you. Greg ---- T.E.A.R Encodes And Rips http://tear.sourceforge.net |