abcde writes wrong play times to MP3 files





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







3















I don't know any solution to my problem. I don't even know the cause and have a hard time trying to find it.



I am ripping my Audio CDs using abcde, which is, basically, working well. It is configured to create both FLAC and MP3 output files as I want to have a lossless archive of my CDs in case they get damaged or lost. The MP3 files are for daily use.



Now to the problem: While the FLAC files get the correct play times written in their metadata, all of my MP3 files get wrong durations written in their tags.



Here is an example exiftool reading (while it's basically for image files, it works with pretty much metadata formats, and yes, ID3 tag readers show the same results):



$ exiftool -Duration *
======== 01 - Rock or Bust.flac
Duration : 0:03:03
======== 01 - Rock or Bust.mp3
Duration : 0:25:02 (approx)
======== 02 - Play Ball.flac
Duration : 0:02:47
======== 02 - Play Ball.mp3
Duration : 0:02:15 (approx)
======== 03 - Rock the Blues Away.flac
Duration : 0:03:24
======== 03 - Rock the Blues Away.mp3
Duration : 0:02:45 (approx)
======== 04 - Miss Adventure.flac
Duration : 0:02:57
======== 04 - Miss Adventure.mp3
Duration : 0:23:18 (approx)
======== 05 - Dogs of War.flac
Duration : 0:03:35
======== 05 - Dogs of War.mp3
Duration : 0:29:40 (approx)
======== 06 - Got Some Rock & Roll Thunder.flac
Duration : 0:03:22
======== 06 - Got Some Rock & Roll Thunder.mp3
Duration : 0:02:42 (approx)
======== 07 - Hard Times.flac
Duration : 0:02:44
======== 07 - Hard Times.mp3
Duration : 0:02:14 (approx)
======== 08 - Baptism by Fire.flac
Duration : 0:03:30
======== 08 - Baptism by Fire.mp3
Duration : 0:27:25 (approx)
======== 09 - Rock the House.flac
Duration : 0:02:42
======== 09 - Rock the House.mp3
Duration : 0:02:44 (approx)
======== 10 - Sweet Candy.flac
Duration : 0:03:09
======== 10 - Sweet Candy.mp3
Duration : 0:25:18 (approx)
======== 11 - Emission Control.flac
Duration : 0:03:41
======== 11 - Emission Control.mp3
Duration : 0:30:57 (approx)
22 image files read


I just don't get the clue, why this is happening. Does anyone know a solution to this?



Solution



Thanks to Phreds hint on missing VBR headers, I discovered the reason for this to happen.



As it turns out, lame's --nogap option was activated in .abcde.conf. It's mentioned neither in the lame manpage nor in the .abcde.conf comments (my version, at least), that enabling this option disables the Xing header. In the abcde manpage, however, this behaviour is mentioned regarding the -g flag.
Corresponding variable in .abcde.conf is NOGAP










share|improve this question































    3















    I don't know any solution to my problem. I don't even know the cause and have a hard time trying to find it.



    I am ripping my Audio CDs using abcde, which is, basically, working well. It is configured to create both FLAC and MP3 output files as I want to have a lossless archive of my CDs in case they get damaged or lost. The MP3 files are for daily use.



    Now to the problem: While the FLAC files get the correct play times written in their metadata, all of my MP3 files get wrong durations written in their tags.



    Here is an example exiftool reading (while it's basically for image files, it works with pretty much metadata formats, and yes, ID3 tag readers show the same results):



    $ exiftool -Duration *
    ======== 01 - Rock or Bust.flac
    Duration : 0:03:03
    ======== 01 - Rock or Bust.mp3
    Duration : 0:25:02 (approx)
    ======== 02 - Play Ball.flac
    Duration : 0:02:47
    ======== 02 - Play Ball.mp3
    Duration : 0:02:15 (approx)
    ======== 03 - Rock the Blues Away.flac
    Duration : 0:03:24
    ======== 03 - Rock the Blues Away.mp3
    Duration : 0:02:45 (approx)
    ======== 04 - Miss Adventure.flac
    Duration : 0:02:57
    ======== 04 - Miss Adventure.mp3
    Duration : 0:23:18 (approx)
    ======== 05 - Dogs of War.flac
    Duration : 0:03:35
    ======== 05 - Dogs of War.mp3
    Duration : 0:29:40 (approx)
    ======== 06 - Got Some Rock & Roll Thunder.flac
    Duration : 0:03:22
    ======== 06 - Got Some Rock & Roll Thunder.mp3
    Duration : 0:02:42 (approx)
    ======== 07 - Hard Times.flac
    Duration : 0:02:44
    ======== 07 - Hard Times.mp3
    Duration : 0:02:14 (approx)
    ======== 08 - Baptism by Fire.flac
    Duration : 0:03:30
    ======== 08 - Baptism by Fire.mp3
    Duration : 0:27:25 (approx)
    ======== 09 - Rock the House.flac
    Duration : 0:02:42
    ======== 09 - Rock the House.mp3
    Duration : 0:02:44 (approx)
    ======== 10 - Sweet Candy.flac
    Duration : 0:03:09
    ======== 10 - Sweet Candy.mp3
    Duration : 0:25:18 (approx)
    ======== 11 - Emission Control.flac
    Duration : 0:03:41
    ======== 11 - Emission Control.mp3
    Duration : 0:30:57 (approx)
    22 image files read


    I just don't get the clue, why this is happening. Does anyone know a solution to this?



    Solution



    Thanks to Phreds hint on missing VBR headers, I discovered the reason for this to happen.



    As it turns out, lame's --nogap option was activated in .abcde.conf. It's mentioned neither in the lame manpage nor in the .abcde.conf comments (my version, at least), that enabling this option disables the Xing header. In the abcde manpage, however, this behaviour is mentioned regarding the -g flag.
    Corresponding variable in .abcde.conf is NOGAP










    share|improve this question



























      3












      3








      3








      I don't know any solution to my problem. I don't even know the cause and have a hard time trying to find it.



      I am ripping my Audio CDs using abcde, which is, basically, working well. It is configured to create both FLAC and MP3 output files as I want to have a lossless archive of my CDs in case they get damaged or lost. The MP3 files are for daily use.



      Now to the problem: While the FLAC files get the correct play times written in their metadata, all of my MP3 files get wrong durations written in their tags.



      Here is an example exiftool reading (while it's basically for image files, it works with pretty much metadata formats, and yes, ID3 tag readers show the same results):



      $ exiftool -Duration *
      ======== 01 - Rock or Bust.flac
      Duration : 0:03:03
      ======== 01 - Rock or Bust.mp3
      Duration : 0:25:02 (approx)
      ======== 02 - Play Ball.flac
      Duration : 0:02:47
      ======== 02 - Play Ball.mp3
      Duration : 0:02:15 (approx)
      ======== 03 - Rock the Blues Away.flac
      Duration : 0:03:24
      ======== 03 - Rock the Blues Away.mp3
      Duration : 0:02:45 (approx)
      ======== 04 - Miss Adventure.flac
      Duration : 0:02:57
      ======== 04 - Miss Adventure.mp3
      Duration : 0:23:18 (approx)
      ======== 05 - Dogs of War.flac
      Duration : 0:03:35
      ======== 05 - Dogs of War.mp3
      Duration : 0:29:40 (approx)
      ======== 06 - Got Some Rock & Roll Thunder.flac
      Duration : 0:03:22
      ======== 06 - Got Some Rock & Roll Thunder.mp3
      Duration : 0:02:42 (approx)
      ======== 07 - Hard Times.flac
      Duration : 0:02:44
      ======== 07 - Hard Times.mp3
      Duration : 0:02:14 (approx)
      ======== 08 - Baptism by Fire.flac
      Duration : 0:03:30
      ======== 08 - Baptism by Fire.mp3
      Duration : 0:27:25 (approx)
      ======== 09 - Rock the House.flac
      Duration : 0:02:42
      ======== 09 - Rock the House.mp3
      Duration : 0:02:44 (approx)
      ======== 10 - Sweet Candy.flac
      Duration : 0:03:09
      ======== 10 - Sweet Candy.mp3
      Duration : 0:25:18 (approx)
      ======== 11 - Emission Control.flac
      Duration : 0:03:41
      ======== 11 - Emission Control.mp3
      Duration : 0:30:57 (approx)
      22 image files read


      I just don't get the clue, why this is happening. Does anyone know a solution to this?



      Solution



      Thanks to Phreds hint on missing VBR headers, I discovered the reason for this to happen.



      As it turns out, lame's --nogap option was activated in .abcde.conf. It's mentioned neither in the lame manpage nor in the .abcde.conf comments (my version, at least), that enabling this option disables the Xing header. In the abcde manpage, however, this behaviour is mentioned regarding the -g flag.
      Corresponding variable in .abcde.conf is NOGAP










      share|improve this question
















      I don't know any solution to my problem. I don't even know the cause and have a hard time trying to find it.



      I am ripping my Audio CDs using abcde, which is, basically, working well. It is configured to create both FLAC and MP3 output files as I want to have a lossless archive of my CDs in case they get damaged or lost. The MP3 files are for daily use.



      Now to the problem: While the FLAC files get the correct play times written in their metadata, all of my MP3 files get wrong durations written in their tags.



      Here is an example exiftool reading (while it's basically for image files, it works with pretty much metadata formats, and yes, ID3 tag readers show the same results):



      $ exiftool -Duration *
      ======== 01 - Rock or Bust.flac
      Duration : 0:03:03
      ======== 01 - Rock or Bust.mp3
      Duration : 0:25:02 (approx)
      ======== 02 - Play Ball.flac
      Duration : 0:02:47
      ======== 02 - Play Ball.mp3
      Duration : 0:02:15 (approx)
      ======== 03 - Rock the Blues Away.flac
      Duration : 0:03:24
      ======== 03 - Rock the Blues Away.mp3
      Duration : 0:02:45 (approx)
      ======== 04 - Miss Adventure.flac
      Duration : 0:02:57
      ======== 04 - Miss Adventure.mp3
      Duration : 0:23:18 (approx)
      ======== 05 - Dogs of War.flac
      Duration : 0:03:35
      ======== 05 - Dogs of War.mp3
      Duration : 0:29:40 (approx)
      ======== 06 - Got Some Rock & Roll Thunder.flac
      Duration : 0:03:22
      ======== 06 - Got Some Rock & Roll Thunder.mp3
      Duration : 0:02:42 (approx)
      ======== 07 - Hard Times.flac
      Duration : 0:02:44
      ======== 07 - Hard Times.mp3
      Duration : 0:02:14 (approx)
      ======== 08 - Baptism by Fire.flac
      Duration : 0:03:30
      ======== 08 - Baptism by Fire.mp3
      Duration : 0:27:25 (approx)
      ======== 09 - Rock the House.flac
      Duration : 0:02:42
      ======== 09 - Rock the House.mp3
      Duration : 0:02:44 (approx)
      ======== 10 - Sweet Candy.flac
      Duration : 0:03:09
      ======== 10 - Sweet Candy.mp3
      Duration : 0:25:18 (approx)
      ======== 11 - Emission Control.flac
      Duration : 0:03:41
      ======== 11 - Emission Control.mp3
      Duration : 0:30:57 (approx)
      22 image files read


      I just don't get the clue, why this is happening. Does anyone know a solution to this?



      Solution



      Thanks to Phreds hint on missing VBR headers, I discovered the reason for this to happen.



      As it turns out, lame's --nogap option was activated in .abcde.conf. It's mentioned neither in the lame manpage nor in the .abcde.conf comments (my version, at least), that enabling this option disables the Xing header. In the abcde manpage, however, this behaviour is mentioned regarding the -g flag.
      Corresponding variable in .abcde.conf is NOGAP







      mp3 ripping id3






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 15 '15 at 21:02







      WolleTD

















      asked Dec 24 '14 at 13:39









      WolleTDWolleTD

      183




      183






















          1 Answer
          1






          active

          oldest

          votes


















          1














          I was having a very similar problem (except that I wasn't using FLAC - the original rip was to WAV instead, I believe). I used a program called mp3diags (running on Ubuntu 14.04) to track it down.



          Turns out in my case the problem was that the encoder had written the mp3 files without a "Xing header" (whatever that might be). mp3diags claimed that VBR without the Xing header would confuse some players. There is an option in mp3diags to "Repair VBR Data". I used this option on the affected mp3 files and they now display correct times in Clementine (audio player).






          share|improve this answer


























          • Could you please detail the usage of the command for the benefit of the OP?

            – Rui F Ribeiro
            Nov 17 '15 at 16:58











          • Walkthrough, assuming mp3diags (mine: version 1.0.12.079) is already installed and working: 1) Launch mp3diags; select dir with malformed files. Allow to scan files. 2) Verify that your files have same problem as mine did. In the listing below files (middle "pane" of the window), in the "L" column, flag is labeled "bg" and description is "The MPEG audio stream uses VBR but a Xing header wasn't found..." 3) Click hammer/downarrow icon just to right of path to bring down menu. From menu, select option "Repair VBR data". Answer "Yes" to "Apply transformation..." dialog. 4) Wait, then quit.

            – Phred
            Nov 17 '15 at 17:26













          • Thank you, that helped. For clarity: I'm ripping to WAV and converting to FLAC and MP3 from there. I still have to find out, why abcde creates these files. As I just tested encoding a (decoded FLAC-) WAV-file manually (with lame --preset extreme), it obviously generated valid Xing headers.

            – WolleTD
            Dec 9 '15 at 13:41













          • Just fond the reason for this to happen. Updated my question.

            – WolleTD
            Dec 15 '15 at 21:03












          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f175779%2fabcde-writes-wrong-play-times-to-mp3-files%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          I was having a very similar problem (except that I wasn't using FLAC - the original rip was to WAV instead, I believe). I used a program called mp3diags (running on Ubuntu 14.04) to track it down.



          Turns out in my case the problem was that the encoder had written the mp3 files without a "Xing header" (whatever that might be). mp3diags claimed that VBR without the Xing header would confuse some players. There is an option in mp3diags to "Repair VBR Data". I used this option on the affected mp3 files and they now display correct times in Clementine (audio player).






          share|improve this answer


























          • Could you please detail the usage of the command for the benefit of the OP?

            – Rui F Ribeiro
            Nov 17 '15 at 16:58











          • Walkthrough, assuming mp3diags (mine: version 1.0.12.079) is already installed and working: 1) Launch mp3diags; select dir with malformed files. Allow to scan files. 2) Verify that your files have same problem as mine did. In the listing below files (middle "pane" of the window), in the "L" column, flag is labeled "bg" and description is "The MPEG audio stream uses VBR but a Xing header wasn't found..." 3) Click hammer/downarrow icon just to right of path to bring down menu. From menu, select option "Repair VBR data". Answer "Yes" to "Apply transformation..." dialog. 4) Wait, then quit.

            – Phred
            Nov 17 '15 at 17:26













          • Thank you, that helped. For clarity: I'm ripping to WAV and converting to FLAC and MP3 from there. I still have to find out, why abcde creates these files. As I just tested encoding a (decoded FLAC-) WAV-file manually (with lame --preset extreme), it obviously generated valid Xing headers.

            – WolleTD
            Dec 9 '15 at 13:41













          • Just fond the reason for this to happen. Updated my question.

            – WolleTD
            Dec 15 '15 at 21:03
















          1














          I was having a very similar problem (except that I wasn't using FLAC - the original rip was to WAV instead, I believe). I used a program called mp3diags (running on Ubuntu 14.04) to track it down.



          Turns out in my case the problem was that the encoder had written the mp3 files without a "Xing header" (whatever that might be). mp3diags claimed that VBR without the Xing header would confuse some players. There is an option in mp3diags to "Repair VBR Data". I used this option on the affected mp3 files and they now display correct times in Clementine (audio player).






          share|improve this answer


























          • Could you please detail the usage of the command for the benefit of the OP?

            – Rui F Ribeiro
            Nov 17 '15 at 16:58











          • Walkthrough, assuming mp3diags (mine: version 1.0.12.079) is already installed and working: 1) Launch mp3diags; select dir with malformed files. Allow to scan files. 2) Verify that your files have same problem as mine did. In the listing below files (middle "pane" of the window), in the "L" column, flag is labeled "bg" and description is "The MPEG audio stream uses VBR but a Xing header wasn't found..." 3) Click hammer/downarrow icon just to right of path to bring down menu. From menu, select option "Repair VBR data". Answer "Yes" to "Apply transformation..." dialog. 4) Wait, then quit.

            – Phred
            Nov 17 '15 at 17:26













          • Thank you, that helped. For clarity: I'm ripping to WAV and converting to FLAC and MP3 from there. I still have to find out, why abcde creates these files. As I just tested encoding a (decoded FLAC-) WAV-file manually (with lame --preset extreme), it obviously generated valid Xing headers.

            – WolleTD
            Dec 9 '15 at 13:41













          • Just fond the reason for this to happen. Updated my question.

            – WolleTD
            Dec 15 '15 at 21:03














          1












          1








          1







          I was having a very similar problem (except that I wasn't using FLAC - the original rip was to WAV instead, I believe). I used a program called mp3diags (running on Ubuntu 14.04) to track it down.



          Turns out in my case the problem was that the encoder had written the mp3 files without a "Xing header" (whatever that might be). mp3diags claimed that VBR without the Xing header would confuse some players. There is an option in mp3diags to "Repair VBR Data". I used this option on the affected mp3 files and they now display correct times in Clementine (audio player).






          share|improve this answer















          I was having a very similar problem (except that I wasn't using FLAC - the original rip was to WAV instead, I believe). I used a program called mp3diags (running on Ubuntu 14.04) to track it down.



          Turns out in my case the problem was that the encoder had written the mp3 files without a "Xing header" (whatever that might be). mp3diags claimed that VBR without the Xing header would confuse some players. There is an option in mp3diags to "Repair VBR Data". I used this option on the affected mp3 files and they now display correct times in Clementine (audio player).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 2 hours ago









          Rui F Ribeiro

          41.9k1483142




          41.9k1483142










          answered Nov 17 '15 at 16:54









          PhredPhred

          262




          262













          • Could you please detail the usage of the command for the benefit of the OP?

            – Rui F Ribeiro
            Nov 17 '15 at 16:58











          • Walkthrough, assuming mp3diags (mine: version 1.0.12.079) is already installed and working: 1) Launch mp3diags; select dir with malformed files. Allow to scan files. 2) Verify that your files have same problem as mine did. In the listing below files (middle "pane" of the window), in the "L" column, flag is labeled "bg" and description is "The MPEG audio stream uses VBR but a Xing header wasn't found..." 3) Click hammer/downarrow icon just to right of path to bring down menu. From menu, select option "Repair VBR data". Answer "Yes" to "Apply transformation..." dialog. 4) Wait, then quit.

            – Phred
            Nov 17 '15 at 17:26













          • Thank you, that helped. For clarity: I'm ripping to WAV and converting to FLAC and MP3 from there. I still have to find out, why abcde creates these files. As I just tested encoding a (decoded FLAC-) WAV-file manually (with lame --preset extreme), it obviously generated valid Xing headers.

            – WolleTD
            Dec 9 '15 at 13:41













          • Just fond the reason for this to happen. Updated my question.

            – WolleTD
            Dec 15 '15 at 21:03



















          • Could you please detail the usage of the command for the benefit of the OP?

            – Rui F Ribeiro
            Nov 17 '15 at 16:58











          • Walkthrough, assuming mp3diags (mine: version 1.0.12.079) is already installed and working: 1) Launch mp3diags; select dir with malformed files. Allow to scan files. 2) Verify that your files have same problem as mine did. In the listing below files (middle "pane" of the window), in the "L" column, flag is labeled "bg" and description is "The MPEG audio stream uses VBR but a Xing header wasn't found..." 3) Click hammer/downarrow icon just to right of path to bring down menu. From menu, select option "Repair VBR data". Answer "Yes" to "Apply transformation..." dialog. 4) Wait, then quit.

            – Phred
            Nov 17 '15 at 17:26













          • Thank you, that helped. For clarity: I'm ripping to WAV and converting to FLAC and MP3 from there. I still have to find out, why abcde creates these files. As I just tested encoding a (decoded FLAC-) WAV-file manually (with lame --preset extreme), it obviously generated valid Xing headers.

            – WolleTD
            Dec 9 '15 at 13:41













          • Just fond the reason for this to happen. Updated my question.

            – WolleTD
            Dec 15 '15 at 21:03

















          Could you please detail the usage of the command for the benefit of the OP?

          – Rui F Ribeiro
          Nov 17 '15 at 16:58





          Could you please detail the usage of the command for the benefit of the OP?

          – Rui F Ribeiro
          Nov 17 '15 at 16:58













          Walkthrough, assuming mp3diags (mine: version 1.0.12.079) is already installed and working: 1) Launch mp3diags; select dir with malformed files. Allow to scan files. 2) Verify that your files have same problem as mine did. In the listing below files (middle "pane" of the window), in the "L" column, flag is labeled "bg" and description is "The MPEG audio stream uses VBR but a Xing header wasn't found..." 3) Click hammer/downarrow icon just to right of path to bring down menu. From menu, select option "Repair VBR data". Answer "Yes" to "Apply transformation..." dialog. 4) Wait, then quit.

          – Phred
          Nov 17 '15 at 17:26







          Walkthrough, assuming mp3diags (mine: version 1.0.12.079) is already installed and working: 1) Launch mp3diags; select dir with malformed files. Allow to scan files. 2) Verify that your files have same problem as mine did. In the listing below files (middle "pane" of the window), in the "L" column, flag is labeled "bg" and description is "The MPEG audio stream uses VBR but a Xing header wasn't found..." 3) Click hammer/downarrow icon just to right of path to bring down menu. From menu, select option "Repair VBR data". Answer "Yes" to "Apply transformation..." dialog. 4) Wait, then quit.

          – Phred
          Nov 17 '15 at 17:26















          Thank you, that helped. For clarity: I'm ripping to WAV and converting to FLAC and MP3 from there. I still have to find out, why abcde creates these files. As I just tested encoding a (decoded FLAC-) WAV-file manually (with lame --preset extreme), it obviously generated valid Xing headers.

          – WolleTD
          Dec 9 '15 at 13:41







          Thank you, that helped. For clarity: I'm ripping to WAV and converting to FLAC and MP3 from there. I still have to find out, why abcde creates these files. As I just tested encoding a (decoded FLAC-) WAV-file manually (with lame --preset extreme), it obviously generated valid Xing headers.

          – WolleTD
          Dec 9 '15 at 13:41















          Just fond the reason for this to happen. Updated my question.

          – WolleTD
          Dec 15 '15 at 21:03





          Just fond the reason for this to happen. Updated my question.

          – WolleTD
          Dec 15 '15 at 21:03


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f175779%2fabcde-writes-wrong-play-times-to-mp3-files%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          CARDNET

          Boot-repair Failure: Unable to locate package grub-common:i386

          濃尾地震