• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

CE2mp3

Started by cyber, 2009.06.12, 12:05:45

Previous topic - Next topic

cyber

Quote from: CDRWSel on 2009.07.13, 23:36:55
I updated your prog for use with cdrwbar.
I include both into the same zip file
(test not done)

Single file: Progress bar, down line where "Track:" is, does not 'travel' from left to right; not show real progres during conversion. It stay at beggining until end, then just jump to the end of line when finishing.
Directory: it fails with:
  140 +++         Call sysleep 5 / 2;
REX0043: Error 43 running C:\TOOLS\M600\ce2mp3-cdrw\CE2MP3_rd.cmd, line 140:
Routine not found
   43 +++     Call ProcDir;

:)))  After correcting typo (syssleep) it is working like single file mode, except that top bar wich represent track n/n show correct possition when jump to next file.
Little more to perfection !!! :)

* Use FFMPEG R18731 build *  All the time. :)



cyber

Quote from: CDRWSel on 2009.07.14, 09:47:05
Have a look into the CE2MP3 included into the zip file.
I've added a few changes as suggestions with a comment + "RD" flag
e.g. replace temp file by a rxqueue etc...
Well done, continue...  ;)

Nice. But progress bar should travel from left to right during FFMPEG making conversion ?

CDRWSel

Sorry for the typo  ::)

Yes it should. Doesn't it   ???  (I would like see a screen copy about the exact pb - small size)
when, starting the progress bar, the parameter tells him the product to monitor (it could be dvddao) and ffmpeg (more are planned...). When ffmpeg is used, the parameter can be "FFMPEG" or "AFFMPEG" to make a difference between video and audio tacks. If more than 1 track is going to be converted and stop of progress bar isn't wanted at end of first track, add the number of tracks appended to the parameter like : ffmpeg5 (progress bar if than left open and is waiting to a total of 5 ffmpeg run (if an error occurs, it stops else it stay open and wait until completion)
       
Progress bar "turtle" is starting when correct information is returned into the pipe. If the program start before te progress bar is enabled to read the pipe, some datas may be lost ! (try to increase the wait time just after the cdrwbar start and before the ffmpeg command. e.g. add 3s (you can reduce it after test))

In case of trouble with cdrwbar, you can kill it or send a "ffmepg -h 2>/pipe/ffmpeg command". Canceling the ffmpeg command gives an error and closes cdrwbar too.

May be you can email me at free.fr
r.dodin       

Batchheizer

Quote from: cyber on 2009.07.14, 09:38:01
If only tagv1 at source exist, it will be copyed to tagv1 and v2 at target mp3.
OK
Quote from: cyber on 2009.07.14, 09:38:01
If tagv1 and tagv2 at source exist, it will be copyed as tagv1->tagv1 and tagv2->tagv2 ?
OK
Quote from: cyber on 2009.07.14, 09:38:01
And if tagv2 exist and tagv1 does not, it will be just tagv2->tagv2 !
Is this OK ?
In the last case copy tagv2 to tagv1. Maybe they are cutted - but this is better than none ID3V1- because many OS2-porgrams can only read ID3V1 (minta; CW_Classes etc.).



cyber

To CDRWSel:

First bar (bar1) stays unchanged to the end of conversion. At the end is updated like bar2.


To Batchheizer:
>In the last case copy tagv2 to tagv1. Maybe they are cutted - but this is >better than none...

OK, but it may happend when unicode is used for tagv2 to look like garbage in tagv1 ?
Have any mp3 with tagv2 unicode characters, i've search web to find some files for test but find only files with tagv1 only and tagv1 identical to tagv2 ?  Link or if files cyber<et>nscable<dot>net

cyber

To Batchheizer:


As ID3v2 can handle to many frames, I've suggest to chose only those below:

COMM    [#sec4.11 Comments]
TCOM    [#TCOM Composer]
TCON    [#TCON Content type]
TEXT    [#TEXT Lyricist/Text writer]
TIT1    [#TIT1 Content group description]
TIT2    [#TIT2 Title/songname/content description]
TPE1    [#TPE1 Lead performer(s)/Soloist(s)]
TPE2    [#TPE2 Band/orchestra/accompaniment]
TPOS    [#TPOS Part of a set]
TRCK    [#TRCK Track number/Position in set]
TSSE    [#TSEE Software/Hardware and settings used for encoding]
TYER    [#TYER Year]

suggestions ?

CDRWSel

Hi Cyber,
Ok, I understand
I would like see the logs of the process (to see them, click on "file->logs" because the progress bar can only progress if ffmpeg returns progression messages like:
size=      77kB time=3.29 bitrate= 191.1kbits/s   
size=     156kB time=6.69 bitrate= 191.5kbits/s   
size=     238kB time=10.16 bitrate= 191.7kbits/s   
size=     321kB time=13.71 bitrate= 191.8kbits/s   
size=     400kB time=17.08 bitrate= 191.8kbits/s   
size=     481kB time=20.56 bitrate= 191.8kbits/s   
size=     562kB time=23.98 bitrate= 191.9kbits/s   
size=     644kB time=27.51 bitrate= 191.9kbits/s   
...
From the total duration (found into the logs) and the time, I calculate the % of total process done. Each "size" entry gives a new progress to the bar  ( saw one time only missing size entries )   
Remy

cyber

Logs in attachments, there is no any trace of 'total duration' in both logs. In FFMPEG output in general I see nothing useful that can give any clue of how more of conversion is done. Maybe -verbose <switch> is missing ?

CDRWSel

Ok,

Here is the problem. Well do a try adding the -v flag but I'm not sure it will help
Do you know how this ogg file was created ?

Look at my attached log, it is much different and here is the command I used for the test:
ffmpeg -y -i "f:\ogg_tracks\track03.ogg" -ab 128k -ar 44100 -ac 2 "track03.mp3" 2>affmpeg.txt

I will think for a bypass...
Remy 

CDRWSel

#69
Hi cyber !

Bypass found and implemented. (use of ogginfo which returns duration and this value is sent thue pipe to cdrwbar).
See modified ce2mp3 with comments into this zip file
Use updated cdrwbar with support of new special options.
;) 

Tell me if it is ok now.
Remy

Batchheizer

Quote from: cyber on 2009.07.14, 15:32:44
To Batchheizer:


As ID3v2 can handle to many frames, I've suggest to chose only those below:

COMM    [#sec4.11 Comments]
TCOM    [#TCOM Composer]
TCON    [#TCON Content type]
TEXT    [#TEXT Lyricist/Text writer]
TIT1    [#TIT1 Content group description]
TIT2    [#TIT2 Title/songname/content description]
TPE1    [#TPE1 Lead performer(s)/Soloist(s)]
TPE2    [#TPE2 Band/orchestra/accompaniment]
TPOS    [#TPOS Part of a set]
TRCK    [#TRCK Track number/Position in set]
TSSE    [#TSEE Software/Hardware and settings used for encoding]
TYER    [#TYER Year]

suggestions ?

I think this sounds good.OGGs mostly do not have so much tags.

cyber

It miss oggtag: routine wich probably should determine Vrun_time ?

You do not test Your programs, or this work on Your machine ?

But if You analyse with ogginfo, then this solution is for ogg input files only. It is better to use ffmpeg with -i to got duration, and then calculate progress with time=nn from duration ?  Then this can be usefull for any format that FFMPEG support ?

  Duration: 00:03:10.81, start: 0.000000, bitrate: 90 kb/s
    Stream #0.0: Audio: vorbis, 44100 Hz, mono, s16, 110 kb/s
Output #0, mp3, to 'HanyuShuipingKaoshi.mp3':
    Stream #0.0: Audio: libmp3lame, 44100 Hz, stereo, s16, 64 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
size=    1491kB time=190.85 bitrate=  64.0kbits/s

CDRWSel

#72
Right, I didn't the test with your CE2MP3 I updated to give you some suggestions but fully test was done with a small rexx I wrote to validate cdrwbar process.
.
CDRWBAR uses ffmpeg information returned during convertion process and sent through the pipe like I wrote it previously (ffmpeg always returnes duration with all test I did and with any kind of supported files) but the logs you provided show that ffmpeg didn't return this information for your tracks or different control chars exist preventing message trapping ! (i added this option to allow a bypass in case of problems like you have and duration can be calculated or extract from any tools or process you want and pass it to cdrwbar as default with this new options but cdrwbar always uses the last duration value received. If ffmpeg send one, it is taken and used instead of the default provide outside of the ffmpeg convertion) or may be something got wrong under your system and I would like see the logs issued from a ffmpeg command with  2>ffmpeg.log  added as last parm to compare. I'm sure it is going to work as well as under my system  ;)
Thanks
Remy

note: just replace ogginfo by ffmpeg and extract the duration, this one will be passed as default duration value for the current track if you prefer but why is ffmpeg sending you duration value when not converting file ? ( pleasen do a try outside of CE2MP3 (command line) using following example: ffmpeg -y -i "your_ogg_track" -ab 192k -ar 44100 -ac 2 "your_mp3_outtrack" 2>/pipe/ffmpeg  just after starting cdrwbar like:  cdrwbar affmpeg )  

cyber

Quote from: CDRWSel on 2009.07.16, 12:10:07
Right, I didn't the test with your CE2MP3 I updated to give you some suggestions but fully test was done with a small rexx I wrote to validate cdrwbar process.

Can You provide this small rexx to test to ?

Quote from: CDRWSel on 2009.07.16, 12:10:07
CDRWBAR uses ffmpeg information returned during convertion process and sent through the pipe like I wrote it previously (ffmpeg always returnes duration with all test I did and with any kind of supported files) but the logs you provided show that ffmpeg didn't return this information for your tracks or different control chars exist preventing message trapping ! (i added this option to allow a bypass in case

I've tested this on several ways with lot of different files.  FFMPEG do provide information on duration with every file I tried.  It does not give this part of information WHEN is used 2>pipe/ffmpeg switch (at least it isn't shown in cdrwbar log)  with every file I tried.  Why is this happen I do not know. I want to test this on my home machine, but have not enough time yet.  Probably someone else could try test this ?


Quote from: CDRWSel on 2009.07.16, 12:10:07
note: just replace ogginfo by ffmpeg and extract the duration, this one will be passed as default duration value for the current track if you prefer but why is ffmpeg sending you duration value when not converting file ?

Where ? Whole ogginfo: routine is missing ?

Quote from: CDRWSel on 2009.07.16, 12:10:07
( pleasen do a try outside of CE2MP3 (command line) using following example: ffmpeg -y -i "your_ogg_track" -ab 192k -ar 44100 -ac 2 "your_mp3_outtrack" 2>/pipe/ffmpeg  just after starting cdrwbar like:  cdrwbar affmpeg )  

in command line when I start cdrwbar using 'start cdrwbar affmpeg' and after that:
'ffmpeg -y -i "your_ogg_track" -ab 192k -ar 44100 -ac 2 "your_mp3_outtrack" 2>/pipe/ffmpeg' cdrwbar does not see anything, and ffmpeg give out like this
C:\Tools\M600\ce2mp3-cdrw>ffmpeg -y -i I:\vid\TestDir\HanyuShuipingKaoshi.o 9:35
FFmpeg version SVN-r18731, Copyright (c) 2000-2009 Fabrice Bellard, et al.
  configuration: --prefix=/extras --enable-gpl --enable-libmp3lame --enable-libg
sm --enable-libfaad --enable-libfaac --prefix=/extras --enable-postproc --enable
-nonfree
  libavutil     50. 3. 0 / 50. 3. 0
  libavcodec    52.28. 0 / 52.28. 0
  libavformat   52.32. 0 / 52.32. 0
  libavdevice   52. 2. 0 / 52. 2. 0
  libswscale     0. 7. 1 /  0. 7. 1
  libpostproc   51. 2. 0 / 51. 2. 0
  built on May  3 2009 14:55:37, gcc: 4.4.0
Input #0, ogg, from 'I:\vid\TestDir\HanyuShuipingKaoshi.ogg':
  Duration: 00:03:10.81, start: 0.000000, bitrate: 90 kb/s
    Stream #0.0: Audio: vorbis, 44100 Hz, mono, s16, 110 kb/s
Output #0, mp3, to 'asf.mp3':
    Stream #0.0: Audio: libmp3lame, 44100 Hz, stereo, s16, 192 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
size=    4473kB time=190.85 bitrate= 192.0kbits/s
video:0kB audio:4473kB global headers:0kB muxing overhead 0.000699%

CDRWSel

#74
Hello Cyber,

ogginfo code was not missing but incorect routine was called due to typo error 'timextr' instead of 'timeextr'   ::)

I checked your program and mine small test code and found that the 'pause' you use gives problem.
I added a 'pause' into my code and then I didn't get datas from the pipe  (paused).
I would suggest to not use this 'pause' command which seems for me to impact any pipe process with unpredictable results.
I did a few ogg tracks from a CD-Audio and tried the ce2mp3 on the new created directory.
I added several changes and removed the 'pause' making problems in the code and I updated cdrwbar to accept a CLOSE command which may be issued by ce2mp3.
I included a few screencopy of the process (cdrwbar with ce2mp3 in the background) in the zip file about results after changes.
Now, I suggest you to stop any program using the 'pause' and use a bypass (loop + pull + syssleep...)
This update is fully tested with audio tracks as input as well as some video files on my system   ;)

Please do a try with audio tracks first (e.g. *.ogg)
I tested it on some avi, flv and ts files with correct results too.
Remy

PS: I added an option to disable use of cdrwbar (set the cdrwbar path to "") and one for disable send of extra duration time.

(see added file under next reply - CE2MP3_rd4.zip)