Recherche avancée

Sur d’autres sites (1928)

• bash variable changes in loop with ffmpeg

  17 septembre 2018, par Mike

  I wrote a skript to quickly create short preview clips from vides I recorded on timestamps that I found worth checking out later for cutting.
  My file with the timestamps is written like this

  FILE_NAME1#MM:SS MM:SS
  
  FILE_NAME2#MM:SS MM:SS MM:SS MM:SS

  example :

  MAH01728#02:47 03:34 03:44 05:00 06:08 06:55

  The script looks like this :

  #!/bin/bash
  
  while read f
  
   do
  
  
  
   file=$(echo $f | cut -d"#" -f1)
  
   filename=${file}".MP4"
  
   timestamps=$(echo $f | cut -d"#" -f2)
  
  
  
  for time in $timestamps 
  
   do 
  
    ffmpeg -ss 00:${time}.0 -i "orig/${filename}" -c copy -t 10 "preview/${file}_${time}.MP4"
  
   done
  
  done < $1

  The script gets half of the previews that I want and on the other the filename is messed up and ffmpeg complains that the file is not found :

  orig/714.MP4: No such file or directory
  
  orig/00:58 01:25.MP4: No such file or directory

  So I modified the script for trouble shooting and just put an echo in front of the ffmpeg command - now all file names are correct. What am I missing ?

  ffmpeg -ss 00:01:47.0 -i orig/MAH01714.MP4 -c copy -t 10 preview/MAH01714_01:47.MP4
  
  ffmpeg -ss 00:02:00.0 -i orig/MAH01713.MP4 -c copy -t 10 preview/MAH01713_02:00.MP4
  
  ffmpeg -ss 00:00:58.0 -i orig/MAH01712.MP4 -c copy -t 10 preview/MAH01712_00:58.MP4
  
  ffmpeg -ss 00:01:25.0 -i orig/MAH01712.MP4 -c copy -t 10 preview/MAH01712_01:25.MP4

• Can ffmpeg concatenate mp3 files using the process at audio-joiner.com ?

  7 juin 2020, par Ed999

  I have a dozen or more mp3 audio files, which I need to concatenate into a single mp3 file. The files all have the same bitrate (320 kbps) and sample rate (44.1 kHz), but all of them have differing durations.

  



  I have studied the three methods of concatenation recommended on stackoverflow (How to concatenate two MP4 files using FFmpeg). One method actually works, but when I play back the output file I find that there are noticeable audio artifacts (audible glitches) at each join point.

  



  I've been told that this problem is caused by the input files not having identical duration. This seems likely, because I've had some successes in concatenating audio files with identical bit rate, sample rate, and duration.

  



  I have seen, online, some much more complex scripts which are, at present, miles beyond my understanding. One solution I was directed to required a fairly deep knowledge of Python !

  



  However, my research also included a site at audio-joiner.com - and this had the only completely successful method I've yet found, for files of non-identical duration. That site processed some of my input files, joined the multiple files into one, and the concatenated output file it produced did not have any audible glitches at the joins.

  



  I looked into the process the site was using, hoping to get a clue as to where I've been going wrong, but the script on the site (which looks like ajax-based javascript) is too complex for me to follow.

  



  Because the process seemed to take quite a long time, I wouldn't be too surprised to learn that the mp3 input files are being converted to some other audio format, joined, then converted back to mp3 for the output. But if so, that wouldn't put me off using the process.

  



  Is anyone familiar with the approach being used, and can say whether it might be reproducible using ffmpeg ?

  



  .

  



  ADDED -

  



  There are 7 scripts, in all, listed in the source of the relevant page :

  



  https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js
https://cdnjs.cloudflare.com/ajax/libs/jquery/1.12.0/jquery.min.js
https://static.123apps.com/js/socket.io.js
https://static.123apps.com/js/shared_0.js
https://static.123apps.com/js/shared_1.js
https://static.123apps.com/js/ajoiner.js
https://ajax.googleapis.com/ajax/libs/swfobject/2.2/swfobject.js


  



  .

  



  ADDED -

  



  The successful (javascript) function seems to be this, but it isn't obvious to me why it is succeeding (too complex for me !). Can anyone suggest what approach it is taking ? For example, is it transcoding the mp3 files to an intermediate format, and concatenating the intermediate files ?

  



  function start_join(e){
  l("start_join():"),l(e);
  var t;
  return(t=$.parseJSON(e)) && $("#ajoiner").ajoiner("set_params",t),!0
}

function cancel_join(e){
  return l("cancel_join():"),l(e),!0
}

!function(o){
  var t={
    init:function(e){
      var t=o(this),n=o.extend({lang:{cancel:"Cancel",download:"Download"}},e);
      o(this).data("ajoiner",{o:n,tmp_i:1,pid:-1,params:{}});
      t.data("ajoiner");
      t.ajoiner("_connect"),o("body").bind("socket_connected",function(){t.ajoiner("_connect")})
    },set_params:function(e){
      var t=o(this).data("ajoiner");
      isset(e)?(e.uid=Cookies.get("uid"),t.params=e,t.params.lang_id=lang_id,t.params.host=location.hostname,t.params.hostprotocol=location.protocol,l("socket emit join:"),l(t.params),socket.emit("join",t.params)):error("set_params: params not set")
    },_connect:function(){

      var t=o(this).data("ajoiner");

      l("_connect"),socket.on("join",function(e){
        "progress"==e.message_type?(t.tmp_i,t.tmp_i++,void 0!==getObj("theSWF")&&(getObj("theSWF").set_join_progress(parseInt(e.progress_value)),l("SWF.set_join_progress("+parseInt(e.progress_value)+")")),isset(e.pid)&&(t.pid=e.pid)):"final_result"==e.message_type?(void(e.tmp_i=0)!==getObj("theSWF")&&(getObj("theSWF").join_finished(o.stringifyJSON(e)),l("SWF.join_finished('"+o.stringifyJSON(e)+"')")),last_conv_result=e):"error"==e.message_type&&l(e.error_desc)
      }
    )},_cancel_convert:function(){
      var e=o(this).data("ajoiner");
      0code>

  


• Back on the Salty Track

  12 juin 2011, par Multimedia Mike — General

  After I posted about my initial encounter and frustration with Google’s Native Client (NaCl) SDK and took a deep breath, I realized that I achieved an important proof of concept— I successfully played music using the NaCl SDK audio output interface. Then I started taking a closer read through the (C-based set of) header files and realized I might be able to make a go of it after all. I had much better luck this time and managed to create a proper Native Client interface that allows for controlling playback, presenting metadata, and toggling individual voices (a fascinating tool for studying classic game music).

  I haven’t bothered to post the actual plugin because, really, what’s the point ? I started with NaCl SDK 0.3 which requires Chrome 12, which means terribly limited reach, even among Chrome users. At least, that was true when I restarted this little project. Chrome 12 was formally released this past week. Chrome development really does move at breakneck pace.

  Anyway, here is a static screenshot of what the plugin currently looks like :

  
  
  

  Not pretty, but it does the job.

  Dev Journal
  Various notes based on this outing :

  • Portability : I tested my plugin using Chrome 12 on 64-bit Windows, Mac, and Linux. Mac and Linux both work ; Windows does not.
  • Build System : SDK 0.3 is still lacking in its ability to compile .cpp files (instead of .cc files) ; necessary because libgme is C++ using .cpp files. This requires some build system modification.
  • Getting the interfaces : This is where I got tripped up the first time around. get_browser_interface() from their example actually refers to a parameter passed in through the PPP_InitializeModule() function. The SDK’s template generator renames this to get_browser().
  • Debugging : I feel unstoppable once I have a printf() mechanism available to me during development. To that end, console.log() from JavaScript outputs to Chrome’s built-in JavaScript console log while putting printf() statements in the actual NaCl plugin causes the messages to show up in /.xsession-errors on Linux/X.
  • Size Matters : The binaries generated with the NaCl 0.3 SDK are ridiculously huge. The basic "Hello World" example in C compiles to binaries that are 6.7 MB and 7.8 MB for the 32- and 64-bit builds, respectively. This made me apprehensive to build a full version of SaltyGME that contains all the bells and whistles offered by the library. However, all of the GME code compiled into the binary adds very little size. Curiously, the C++ version of "Hello World" only ranges from 1.8-2.0 MB for 32- and 64-bit. Is there some kind of C tax happening here ? Note that running ’strip’ on the resulting .nexe files (they’re ELF files, after all) brings the sizes down into the C++ range, but at the cost of causing them to not work (more specifically, not even load).
  • No Messaging : The NaCl SDK is supposed to have a messaging interface which allows the NaCl plugin to send asynchronous messages up to the hosting page. When I try to instantiate it, I get a NULL. I’m stuck with the alternative of polling from the JavaScript side to, e.g., determine when a song has finished loading via the network.

  That’s all I can think of for now. I may work on this a little more (I’d like to at least see some audio visualization). Maybe Google will enable NaCl per default sometime around Chrome 21 and this program will be ready for prime time by then.

  See Also :

  • My first attempt at this same project