Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for writing to stdout #8

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

kohlrabi
Copy link

This pull request contains the code which will allow to write to stdout instead of a file, by giving the option --stdout. With that it is possible to pipe the output of ww2ogg to another program for further processing, for example by revorb.

    - Write everything which has been written to stdout to stderr.
    - Redirect ogg bitstream output to stdout
@hcs64
Copy link
Owner

hcs64 commented Nov 2, 2016

This is cool, thanks. Does it really work with revorb?

A few suggested improvements:

  • There's a number of commented out cout lines, I'd prefer these to be made cerr as well
  • I like to check with isatty() before writing to stdout to avoid spewing binary onto the console

Also I'd prefer if you split out the compiler change into a separate pull request, some of my systems still have the i586-mingw32msvc compiler.

@kohlrabi
Copy link
Author

kohlrabi commented Nov 3, 2016

Thanks for the comments, I will split up both changes so that you can pull the stdout patch separately. I have recently tested with revorb (actually, that was the reson for the patch), which supports taking data from stdin by specifying "-" as input file.

@qlyoung
Copy link

qlyoung commented May 1, 2018

@kohlrabi think you could finish up this PR? would be awesome to have it :)

@Mgamerz
Copy link

Mgamerz commented Sep 24, 2018

+1, would appreciate this. I will manually implement this to prevent having to do a bunch of disk I/O in my project, but it would be nice to have it official.

@Mgamerz
Copy link

Mgamerz commented Apr 3, 2019

The one thing about this I have noted is that the receiving program must manually modify the length of the file it receives - the piece of data after RIFF as it is not known at the start time it seems.

@hcs64
Copy link
Owner

hcs64 commented Jun 5, 2021

Cool, thanks! I'll take a look over this soon.

Edit: Oops, that was meant for #23. I'm sorry to have left thing hanging for 4+ years, still not sure what's the best way to approach this. I'll try to get this paged back in and make a decision this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants